And don't forget one more reason: Subversion transmits diffs both
ways, where as CVS always has to do fulltext from client to server.
This should be a huge win for small changes to big files.
-K
Greg Stein <gstein@lyra.org> writes:
> More thoughts from the conference and my conversations with people...
>
> A number of people have asked whether Subversion [and its use of HTTP / DAV]
> will be as fast as CVS. My answer has always been a resounding "yes". Why?
>
> Let's consider the case where SourceForge uses SVN for the projects. SF is
> located in California. Now, let's turn to the European developers trying to
> get stuff out of SF. What should they do? Point their SVN client at a
> caching proxy located in Europe. John checks out some GNOME project, which
> loads it into the cache. (note: versions are immutable, so the cache will
> hold onto that particular version until the cache's FIFO strategy tosses the
> file out; it won't ever expire) Now, Jane comes along and checks out the
> same project. Hey! She gets it directly from the cache. No cross-atlantic
> checkout. Of course, caching proxies at business network edges also provide
> the same benefits.
>
> Also, our SVNDIFF format is quite good. HTTP can also (tranparently) add
> GZIP encoding on top of that automatically. The GZIP will squeeze our diffs
> down, but also original checkouts, too!
>
> HTTP request pipelining allows us to shove a dozen GET and PROPFIND requests
> at the server all at once. We then sit back and wait for each request to be
> returned (rather than send/wait/send/wait).
>
> We also happen to be using one of the most tuned network servers out there
> (Apache). In addition, our repository is based on the Berkeley DB rather
> than files scattered all over the filesystem. And we can just yank a file
> from the repository and send it... no RCS file parsing or watching out for
> @@ codes in the body of the file.
>
> Similar to the caching proxy concept, it is also possible for a site such as
> SF to install a number of cache reverse-proxies in from of their SVN
> repository. As requests are made, they are load-balanced across a number of
> servers which are fulfilling the requests.
>
> >From a protocol standpoint, we are a little heavier than CVS, but I will
> make a guess that it isn't going to be an issue from a complete system
> standpoint. With all the other factors weighing in our favor, the extra 100
> bytes in a request/response just don't seem like a problem.
>
> Of course, we can run our tests later, but I am quite confident that SVN is
> really going to beat CVS quite handily. And when we take advantage of the
> HTTP infrastructure (e.g. caching proxies, web farms, ..) we will *really*
> cream CVS. Heck, things like CVSup or rsync'ing CVS repositories will simply
> disappear in favor of caches.
>
> Fun fun...
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:12 2006