Re: cvs update vs. git pull

René Moser [off-list ref] writes:

One problem we have is, that if there is a commit to cvs while the cvs
update of the build job is running (and this takes 20 minutes), then we
get some inconsistence, the build will fail.

Git will also bring a big performance improvement here. The duration
of the "git pull" will be mostly O(number of modifications since last
pull), not O(total number of files).

So the question is, if we would use git, this inconsistence would not be
possible because the git pull will get the state of the sha1. Right?

Actually, if you use almost anything but CVS (i.e. even SVN can do
that), you will get "atomic commits", i.e. a commit touching multiple
files is either seen as completed or not seen at all.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

On Fri, May 28, 2010 at 09:54, Matthieu Moy
[off-list ref] wrote:

René Moser [off-list ref] writes:

quoted

One problem we have is, that if there is a commit to cvs while the cvs
update of the build job is running (and this takes 20 minutes), then we
get some inconsistence, the build will fail.

Git will also bring a big performance improvement here. The duration
of the "git pull" will be mostly O(number of modifications since last
pull), not O(total number of files).

A while back I tried converting a huge (~40k directories) CVS
repository to SVN and Git. Both CVS and SVN took around 10 minutes to
cvs/svn up. git clone took around 8 minutes but each pull was around
5-15 seconds (I/O and network bound).

They eventually picked Bazaar for non-technical reasons. But yeah,
Git's much faster to upgrade than CVS/SVN.