Re: time to be serious about dropping CVS

[Jonas Maebe <jonas.maebe@elis.ugent.be>]

On 08 Jan 2010, at 14:12, Joel Brobecker wrote:

>> I don't know why CVS is so slow.  Whether it is CPU bound on the
>> sourceware machine, or the bandwidth at the hosting site is at
>> capacity .. who knows?  I'm not even sure how to find out.  But would
>> SVN solve any of the problem relating to performance?
>
> My observations on SVN is that it is a huge I/O hog. I don't know
> what it's doing, and how it encodes it's meta data, but you definitely
> feel it when your home directory is not on a local hard drive.

That's indeed true. As far as I know, it's due to svn creating lock  
files (or lock attributes) in every sub directory of the current  
working directory when performing any operation that might modify  
anything (unless you perform a non-recursive operation, but those are  
rare). I guess the reason is that svn allows treating every  
subdirectory as a separate "repository" should you wish to do so, so  
e.g. a commit in gdb/intl could be executed in parallel with an update  
gdb/bfd, since both would be locked separately. The downside is  
obviously that  updating gdb requires locking gdb/ and also all of its  
subdirectories.

Afaik, in case of git the entire repository is atomic and hence it  
doesn't have to lock/unlock all the subdirectories every time.


Jonas