The basic problem here is that Subversion is not a distributed VCS, in the common sense of the word that means “everybody has their own, separate and different copy of the repository.” Subversion works on the single-central-repo model, and shouldn’t be included in this list at all, if being able to have disconnected operation or not have a shared “master” repository is a requirement.
If you want to compare working within Subversions central-repo model to working within the distributed model of another VCS, that can be a fair enough comparison. But you need to work within the strengths of each VCS. A DVCS would lose on most counts to Subversion if you used Subversion’s working model within a DVCS.

In that light, how does Subversion compare? I’ll be making some specific references to Git in this comparsion since, out of this list, Subversion and Git are the two VCSs I’m most familiar with.

1. I’m not clear what “the fundamental method of collaboration must be a branch” really means, myself. If you need to be able to create commits that do not go to the master repo, Subversion of course fails completely here; it’s not a DVCS! But as far as updates from the central server being a merge into a local branch of work, yes, that’s how Subversion works. Think of your working copy as a (very short) local branch, and that’s exactly how `svn update` works. You can see this as a one-step version of doing a `git stash`, `pull` and `stash pop`, with the provisio that once you’ve done the `svn update`, it’s more work to try to back out of it (though it can be done).

2. Branching is quite cheap in Subversion; it’s just an `svn cp` with two repository URLs. It’s pretty near as cheap as it gets, barring the necessary network I/O overhead. That’s not to say that merging is going to be cheap, just creating a branch is.

3. Merging between branches is indeed poor in Subversion, as of 2006. I understand it’s improved a lot in the past couple of years. I’ve not done enough of this to do a good comparision.

4. No individidual merging of changesets. (I’m not even clear on how this might work in any VCS, if there are conflicts, even if those conflicts are trivially resolved.)

5. Branching does preserve full history in Subversion, since the branch is part of the same repository, and you can easily trace back through the beginning of the branch back into the history that led to the branch point. No, Subversion of course does not support cross-repo branching, because there is only one repo. Th
e question of whether it does or not doesn’t make sense in the Subversion world.

6. Merging does not, as of 2006, preserve full history in Subversion, since the merge is basically just a huge patch. (I generally note in the commit message the branch and revision from which I’m merging when I merge across branches.) I understand in newer versions of Subversion this information is preserved automatically.

7. Subversion does basically nothing off-line except let you compare your local changes to the working copy with the checked-out version, and revert them.

8. Subversion is indeed fast enough for general purpose use.

If you’re working in an environment where you have a centralized, “master” repository which everybody updates frequently and updates from frequently, svn seems to compare reasonably well with the DVCSs except for merging, where as of 2006 it is a ways behind. (Someone else will have to explain what the latest versions of Subversion do to improve this.) It does have the advantage that the system and workflow, being fairly constrained, is in the circumstances generally a bit simpler to use than the DVCSs.

It also supports using git-daemon for public access, as well, again controlled through the configuration file.

Gitosis was one of the big features that convinced me to switch to git.

Without being able to merge easily after cherrypicking, a DVCS really can’t be said support cherrypicking.

http://computerroriginaliascience.blogspot.com/2007/08/how-to-evaluate-dvcs.html

There are many very useful Mercurial extensions that are worth a try.

I’ve been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I

SVN
GIT
Darcs
Arch
baz
Mercurial
bazaar-ng

…

I have this puny little 133MHz laptop which has been working just fine for me over several years. With 32Mb of RAM and Debian Woody, I was able to run X, Emacs, and CVS and basically not worry. Except that CVS is not, you know, distributed.

So I got a RAM upgrade (64Mb is all this puppy can take) and upgraded to Ubuntu Dapper, and installed SVK, because we recently switched to SVN at work and this seemed like the most “natural” way to go distributed. Well, it couldn’t even download 68 revisions of a single text file — it took forever, and failed because of some network error, and had to be unjammed before I could try again, and then it corrupted its repo, and I had to start over from scratch, and eventually, the “oom-killer” thing (I guess “oom” stands for “out of memory”) killed not only svk, but also various and sundry vital system daemons.

Next, since I’m on Ubuntu now, I thought I’d try bzr. Big deal. Basically the same thing — it kept on going and going and going and eventually fell on its face after having consumed up all memory. (And it’s not like I have a small swap space on this machine — I set up like a gigabyte, but I suspect oom-killer will never even allow me to access all of it.)

Next up, darcs. You know what? It just works ™. I’m still too chicken to try to run X again, but Emacs + darcs is a very reasonable combination indeed, even on this modest hardware.

PS. Sorry if the wrapping is screwy, I had to save this to a text file while finding a machine that would be able to look at your CAPTCHA /-:

What I’m thinking of is what git terms “rebasing a branch”. If you’ve been hacking a neat feature on top of baseline version 1.1, and in the mean time baseline version 2.0 has been released, merging your changes in could be messy. You can either merge with 2.0 and fix the conflicts before releasing your changes to the world, or you can “rewrite history” and apply the changes you’ve made to version 2.0, resulting in a branch that looks like you started hacking on version 2.0. This can produce a less tangled branch history, so is appreciated in large projects.

Git’s cherry-pick is BASICALLY diff-and-patch, but it does one diff and patch per change along the branch, so you keep the full development history, AND it checks each patch to see if it has already been applied to the destination branch. If it has, it skips it. (The “git-cherry” helper does that.)

There’s also git-rerere, which remembers merge conflicts that have to be manually fixed and recycles the previous manual resolution if the same conflict has to be fixed again in a later merge or rebase operation.

Neither of these assign a permanent ID number to a particular change (git assigns permanent ID numbers to snapshots, not the deltas between them), but in practice they reduce the incidence of needing to manually resolve the same conflict twice to negligible levels.

The central repo isn’t particularly “authoritative”, though; monotone replication is more like mirroring than like branching, so we can all have equally authoritative copies of our mainline branches.

Possibly useful link about this topic: [url]http://venge.net/monotone/wiki/MasterRepository[/url]

Normally, you use “darcs push” to push to a central server. It uses ssh and run the darcs binary on that server to apply the patches. So all you need is ssh and a darcs binary there, and standard Unix permissions can control the setup.

An alternative is to use signed patches sent over email. The Darcs author, David Roundy, does this. You can simply run “darcs send”, and it will send any patches you have that the central repo doesn’t. The central repo describes where to send the patches to. You can use a simple script on the central server that will check signatures, and if so, pass the patches to darcs apply.

So the requirements are probably a little less than SVN.

If you don’t need to handle multiple users committing simultaneously (and thus don’t need the darcs binary to handle locking and conflicts), you can just rsync your personal repo up to the server.

There is one question I don’t see covered on any comparison of DVCSs. With team collaboration on a project, it is often desirable to maintain a central “authoritative” repository to which several people can commit. So:
How good are the different DVCSs at offering multi-user commits to a remote repository, preferably without requiring shell access on the machine where that repository is kept?
I know SVK is able to offer that, cause the central repository can be a simple SVN server.
Given the rest of the comparison here, darcs might be a viable solution if I/we ever need a distributed VCS.

regards,
Sven

Thus, your #4 works even though you think it won’t… You can cherry-pick changes, merge later, and have everything work perfectly. Seriously. I do this often. The [i]changeset[/i] is [b]not[/b] replayed, re-applied, or anything like that. If the default merge strategy doesn’t work for you, there are others available. Plus, git-rerere will handle some really bizarre cross-merge and rebasing changes for you by recording what you did to resolve those changes last time.

Plus, git-cherry-pick by default will record the tree from which you picked the changes. The gitk viewer uses that as a link, so you can jump to it, etc.

Two holes in git’s toolset right now are cloning with limited history and handling subprojects. Those are better handled by other tools, alas.

2) In monotone, branching is essentially free — committing to a new branch costs exactly the same as committing to an existing branch.

3) Monotone’s merger is pretty smart — it has a few enhancements that would be nice to add at some point, but it’s smarter than 3-way merge, provably correct (for some value of provably), and cleanly handles things like renames (both files and directories), arbitrary attributes on files, etc.

4) Merging individual changesets is trivial — you can ‘mtn pluck’ them out of history and into your workspace, using the smart merger to wiggle them into place. However, future merges are blind to this. The reason this feature is unique to darcs is that, well, no-one knows how to make it actually work — even darcs (cf. the last year+ of traffic on the darcs-traffic list). We’re all watching to see if the darcs devels solve the problem, but until they do, I don’t think anyone else wants to get sucked into the situation where there are users waiting for you to invent new math that may or may not exist.

5 & 6) Of course we preserve history.

7) Actually, in some sense it’s only possible to work with history offline :-). Monotone’s only network operation is “sync my local mirror”; everything else works against local disk. (This might change at some point to support conveniences like history-less checkout, but we’ll see.)

8) “Fast enough for general purpose use” is a bit subjective, but I’d say so. The one potential issue is that initial pulls are somewhat slow, which large projects have worked around by putting up compressed repos for HTTP download. We’re working on fixing this now, as well.

Right, about #1, then — you describe the particular branching model that is popular for DVCS’s these days — I think it originated with BK. It’s not the only possibility. Unfortunately, we don’t have a good potted explanation I can point you to about how monotone does it. But briefly, a project generally has a whole shared namespace of branches. You normally synchronize the whole namespace at a time (though don’t have to). I.e., this namespace is not tied to any particular location; people can commit to “the same” branch while disconnected. Branching is orthogonal to physical location — you only create a new branch when you have some divergence you/your project wants to keep track of. By default, branches are replicated, globally visible, and shared.

There are some rough edges on all this still — fixing those is priority #2 after improving pull speed — but that’s the basic idea.

Cheers,

Looks like I also forgot the last two points:

7. You can create a local branch offline and commit to there. SVK also lets you work with the full history of the remote repository (the part you have mirrored). Once you’re connected again, you can easily pull down new changes from the remote repository and push yours back.

8. SVK is quite fast for general use, but I don’t know how it compares to others. The initial mirroring of a repository can be slow if the repository has many revisions.

I have found this to not be an issue with modern darcs. kdiff3 is especially nice when merging with upstreams that have applied Debian patches already.

I know that the issue exists, but I have only seen it bother me once in actual use. As a practical matter, it isn’t a consideration for me.

So someone trying to track the history of merges will have a terrible time, since bzr log will show a “merged:” line of the source repo at the wrong place. It’s really storing an incorrect history.

Regarding the history preservation, someone sent me information on how to get that out of bzr, so I will update the article. It is completely undocumented in the bzr manpage and bzr diff, and only works for non-cherrypicking, but is nevertheless a valid point.

Personally I’m investigating bzr at the moment.

#2 – Bazaar has a mechanism called ‘repositories’ to do cheap local or remote branching. It works without requiring hardlinks, which is good on OS X and Windows. It helps in some cases where hardlinking cannot, such as bringing down someone else’s branch related to something you already have. It actually works very well, but I acknowledge the documentation is confusing and we should fix that.

#3 – Merging between branches is pretty good. I wouldn’t say that Arch’s merging is much like darcs, but a full comparison is too long for this comment. In particular Arch won’t do darcs’s very cool merging of discontiguous changes without considerable user effort.

#4 – No, bzr is a bit more intelligent than just getting a patch and applying it, though we still want to do more to improve cherry picking. I’m not sure where you got this idea that we will cause nightmares by ignoring partially merged patches; we certainly don’t. There is some design work for improving the tracking of this.

#5 – Bazaar brings across the full history when you branch or merge. We *present* the data as being rolled up, but it’s all still there and you can look at it e.g. with the GUI, and it’s used by merging. The distinctness of the changes is not lost; this is something we specifically fixed compared to Arch.

We also have support for svn-like checkouts where the history is stored remotely and accessed only when needed.

#8 – We’re specifically concentrating on performance as we come up to 1.0. 0.9 will be substantially faster than the previous release.

Bazaar really does not lose history. I wish you would correct that in the article. If you read it somewhere or if there’s something we should make more clear please let me know.

It would certainly be better to be able to do it in one step, but two isn’t bad.

-David

Feature by feature:

1. SVK uses a depot to hold a full mirror of each Subversion repository you want to use. You initialize and then checkout from the mirror. Once a repository is mirrored, you can create a local branch, which retains full history and allows you to commit without network access to or commit permissions on the server. So branching is not “fundamental” in that it requires extra steps, but it is quite simple.

2. Branching is implemented, as in Subversion, as a copy operation. Subversion copies are copy-on-write, so they are cheap and fast.

3. SVK implements merge tracking using a simple push and pull model. It also implements star-merge (based on tla’s algorithm, IIRC).

4. SVK allows you to cherry pick changesets, but it is not very well abstracted at the moment.

5. SVK retains full history on remote branches (i.e., those that happen on the server) and on local branches (i.e., those that happen in your local depot).

6. Merging from one branch to another preserves full history in SVK. SVK calls this an “incremental” merge.

I don’t expect to convert anyone currently using Darcs to SVK, but any DVCS review should at least mention SVK. :-)