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
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
>Bob, can you follow up with investigating how we could get onto that
I'll zag an email to someone.
>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
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... ;-)