Re: time to be serious about dropping CVS

Jonas Maebe
2010-01-08T13:21:35Z

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