[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Large file actual performance report; cvs use of ,v header is someti
RE: Large file actual performance report; cvs use of ,v header is sometimes non-optimal.
Fri, 18 Jan 2008 06:52:26 +1100
> * Source file size (UTF-16LE XML file) after it is reduced
> in size by 50%
> by recoding to UTF-8 is on the order of 50MB plus or minus.
CVSNT (yes it runs on linux and is 'free') has native support for UTF16
files, if using such files then using a server with native support is
probably more sensible.
> At the revision that would be 1.26, it was realized that
> 1.23, 1.24, and
> 1.25 were a dead end and that 1.26 was a rework from 1.22.
> It seemed easy
> enough to delete 1.23, 1.24, and 1.25
No what would have been easy was to do cvs up -j 1.25 -j 1.22 (check
syntax) to 'merge' revision 1.22 to head (making revision 1.22 current).
Again if you are using CVSNT this will also create a mergepoint so you
can 'see' what happened. Since this does not require admin priv it is
obviously much 'easier' than an admin command. A good rule of thumb is
'if you are about to use any cvs admin command then ask if there is a
better way of achieving the same result without the admin command
because there is one'.
> This starts to make it more obvious why CVS use with large
> files is discouraged on list.
I'd personally not call 50M large, over 500M files I'd consider large.
|[Prev in Thread]
||[Next in Thread]|
- RE: Large file actual performance report; cvs use of ,v header is sometimes non-optimal.,
Arthur Barrett <=