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