[boost] Re: Initial Subversion/RapidSVN experience

From: David B. Held (dheld_at_[hidden])
Date: 2005-02-05 13:31:48

Beman Dawes wrote:

> [...]
> ***** Serious Problem ***** The initial checkout seemed to be working my 
> DSL connection pretty hard, so I started Task Manager and monitored 
> "bytes received". By the time the checkout finished, over 800 megabytes 
> had been received! I tried a completely fresh CVS checkout for 
> comparison; the received byte count was 12.5 megabytes. CVS uses 
> compression (although you have to remember to turn it on); I couldn't 
> find any mention of a compression option in the SVN docs, and a search 
> of RapidSVN menus didn't turn up any way to turn on compression. We 
> would need to solve this problem since 800 megabyte checkouts aren't 
> acceptable for dial-up users.

My guess is that the client doesn't properly do compression.  From
http://subversion.tigris.org/:

     * Apache network server option, with WebDAV/DeltaV protocol.

     Subversion can use the HTTP-based WebDAV/DeltaV protocol for
     network communications, and the Apache web server to provide
     repository-side network service. This gives Subversion an
     advantage over CVS in interoperability, and provides various
     key features for free: authentication, path-based authorization,
     wire compression, and basic repository browsing.

So I guess that's a point in favor of an HTTP server over svnserve.
Apparently, there are some issues with some of the SVN clients and
compression, so it doesn't seem unreasonable that RapidSVN is one
of them, considering that it's a pre-release product.  On the other
hand, TortoiseSVN seems decently mature, and apparently leverages
the experience of TortoiseCVS.

> [...]
> * Starting RapidSVN on the Boost SVN working copy is very slow; over 60 
> seconds if the machine has just been turned on. The disk is being worked 
> hard. 10 seconds if the cache is warm. For comparison, WinCVS starts in 
> a second or so, even on a cold disk cache.

Perhaps another point against RapidSVN...for now.  TortoiseSVN has
zero startup time, because it's really just a set of shell
extensions for Windows Explorer.  Pretty hard to beat that (except
with TortoiseCVS, of course ;).  If it isn't obvious by now, I'm
suggesting that you give TortoiseSVN a try.  It might seem a little
cutesy at first, but I think you will be delightfully surprised at
how easy it is to use.

> * The Subversion revision numbering scheme is so different from CVS that 
> it will take quite a bit of reorientation (at least for me) to learn how 
> to use it. It is very counter-intuitive for me that the previous 
> revision of a file isn't 12345 if the current revision is 12346. I found 
> myself constantly having to run "log" to figure out what the previous 
> revision was. I often look at past revisions, so this is important to 
> me. I suppose there is some way to do this as easily as with CVS, but I 
> haven't figured that out yet.

This is one of those things that is just going to be different for
SVN.  As far as SVN is concerned, there are no such things as "tags"
and "branches" and "trunks" and "projects" and "changesets" or
anything like that.  To SVN, each transaction on a repository, no
matter *what* part of the repository, introduces a new repository
tree, and that is exclusively what SVN traffics in.  That is why
changes are numbered with a global revision, rather than a per-file
revision.  Yes, that is quite contrary to the way CVS does it,
and no, I don't think there is an easy way to get CVS-like behavior.
On the other hand, if you want to see an old revision in TortoiseSVN,
you just do a Show Log and double-click on the revision of your
choice.  Not sure if it makes a difference what the revision numbers
are then, as long as they are in order.

> * RapidSVN doesn't save location on exit, so every time you start it up 
> you have to navigate to wherever you want to be. It also crashed on me 
> several times. My sense is it is a nice piece of software, but also very 
> immature as yet.

That's probably true.  Which is why you should take a look at
TortoiseSVN. ;)

> * The branching and tagging approaches seem different; we would have to 
> work out new best practices before switching to SVN.

The SVN book suggests some best practices, which Troy has aparently
followed.  To accomodate the CVS style of thinking, he's created
top-level trunk/tags/branches directories which hold the various
tree copies.  But as someone else mentioned, there is no compelling
reason to do things this way, and it would be just as easy to call
the tags folder "releases".

Dave