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.
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.
Also, does anyone have reservations about making a wholesale switch over to Subversion with the main codebase? I have used Subversion previously and found the commands to be analogous enough to CVS that it didn't take long to learn.
There are conversion tools that will allow the mapping of CVS tags/branches/etc into their SVN equivalents.
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.
Bob