On Wed, Mar 23, 2005 at 04:16:53PM -0600, Bob Jamison wrote:
Bryce Harrington wrote:
Hopefully it will also be faster. I've learned to deal with the other CVS iniquities but there's no way to really get around the performance problems.
SVN is chatty... but since the directory is considered as a whole, and not a set of loose files, it is basically sending a single big diff instead of a collection of small ones. Also, your client will have zip and ssl built-in. Oh, and it does -binary diffs-. So it won't always need to send a complete copy of a binary file the way CVS does. I think that maybe per-text-file it might be slower, but the higher level optimizations should make it faster. And it works on port 80, for firewalled people.
Well, I suspect the main driver here will be the hardware, particularly the quality of it's I/O bus and harddrive speed. Even the best processor and network capabilities can be hamstrung by poorly sized I/O. For large scale systems, that also happens to be pretty expensive to do right, and too easy to cut some corners on...
It would be nice if Inkscape were one of the "specific selected projects".
Bob, can you follow up with investigating how we could get onto that list?
I'll zag an email to someone.
Great, thanks.
The main concern I would have is instability/bugs in their implementation. It sounds like they're going to be testing it pretty heavily though, and svn's been around long enough that the software itself should be stable compared with cvs.
We used it in a development environment for my day job with > 60 MB of source and resources, no problem. And that was two years ago. The only problems in pre-1.0 versions was that the database schema changed occasionally, so upgrading the server was a touchy problem. The devs have promised to not change it again until the next major version.
*Nod* I've also seen it successfully implemented, but then I've also seen CVS implemented much more successfully than at SourceForge... ;-)
Bryce