@boomzilla said:
Firstly, I don't need to be able to access the central repository to be able to commit, branch, etc. I can also clone the repo to multiple places to try something really weird that I don't necessarily want "polluting" the main repo (i.e., a super experimental branch). But not having network connectivity and still being able to work is a huge benefit. This may not be an issue for every project, but only the terminally trolling would even attempt to deny the potential benefit here.
Yes, these are obvious benefits. I don't have a problem with those.
@boomzilla said:
One thing that the DVCSes all seem to get right that most (all?) CVCSes get wrong is that the DVCSes do commit then merge, as opposed to the opposite. This means that if someone commits some changes to a file that you're
working on, before you can commit your changes in, say, subversion, you
have to first merge their changes into your (already modified!) file.
The DVCSes allow you to commit and then you merge the differences. This
allows you to have a record of both changes and how they were
reconciled. There's nothing inherent in CVCS AFAIK that prevents this,
except that the current implementations didn't do it that way. This is a
critical reason why I prefer existing DCVS implementations to CVCS
implementations.
I think I see what you're saying here. With SVN, if you try to commit your change when someone else "commited under you", you get a conflict, and have to resolve that before committing (so the commit is actually of the merge, rather than the individual changes). With Hg, the commit creates an "unnamed branch" which then requires a merge. I find the SVN approach nice because there are fewer steps (it's simply resolve-commit, instead of commit-pull-merge-commit-push) but you do lose the intermediate information that Hg gives you with the unnamed branch.
@boomzilla said:
The DVCSes are generally just better in general in branching and merging. Subversion seems to be improving, but not nearly as good as, say, mercurial or git.
Our experience is that they are all bad - we had to do a bunch of manual repairing in our Hg merges, just as we had to do with SVN. Hg seemed to be worse for us than SVN in one respect, though, in that it did not indicate a conflict and just put stuff in strange places, wheras SVN threw up its arms with a conflict indication. I do admit, though, that this may somehow be related to issues in our process rather than the tool.
As I said, what I don't see is that the benefits of having an "untethered" repository with DVCS outweight the extra management and process steps it requires to ensure everyone has the latest information.
That said, I'm actually coming to be of the opinion that the biggest issue with all VCS is the way projects are set up in terms of branching and merging: if you get the basic setup wrong, the tools may not be able to overcome the bad decisions (such as branching too much of the project, keeping branches alive too long, branches of branches of branches...)