info-cvs
[Top][All Lists]
Advanced

[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


From: Bulgrien, Kevin
Subject: RE: Large file actual performance report; cvs use of ,v header is sometimes non-optimal.
Date: Thu, 17 Jan 2008 16:31:08 -0600

> 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.

OT.

Plug ignored.  CVS-NT not on distribution, no auto-security updates for
5 years.

Besides, not more sensible in this case anyway.  There are numerous side
benefits to not using the native files, but that too is OT.

> 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'.

Also OT.

This is not what was being done and is not relevant to the subject line.
This does not move three revisions from the HEAD stream to a branch.
I wanted the diff noise off of the HEAD and present in a branch.
 
> > 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.  

That's the point isn't it?  Even though not big by your standards, the CVS
server cannot handle a couple of small branches and less than 30 revisions
without consuming hours and hours of server time.  I think that only points
out how valid it is for someone to say that controlling GB sized files in
CVS is quite preposterous.

This email message is for the sole use of the intended recipient(s) and may 
contain General Dynamics SATCOM Technologies confidential or privileged 
information.  Any unauthorized review, use, disclosure or distribution is 
prohibited.  If you are not an intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]