Moving from SVN to HG : branching and backup

Question

My company runs svn right now and we are very familiar with it. However, because we do a lot of concurrent development, merging can become very complicated.. We've been playing with hg and we really like the ability to make fast and effective clones on a per-feature basis.

We've got two main issues we'd like to resolve before we move to hg:

• Branches for erstwhile svn users I'm familiar with the "4 ways to branch in Mercurial" as set out in Steve Losh's article. We think we should "materialise" the branches because I think the dev team will find this the most straightforward way of migrating from svn. Consequently I guess we should follow the "branching with clones" model which means that separate clones for branches are made on the server. While this means that every clone/branch needs to be made on the server and published separately, this isn't too much of an issue for us as we are used to checking out svn branches which come down as separate copies. I'm worried, however, that merging changes and following history may become difficult between branches in this model.
• Backup If programmers in our team make local clones of a branch, how do they backup the local clone? We're used to seeing svn commit messages like this on a feature branch "Interim commit: db function not yet working". I can't see a way of doing this easily in hg.

Advice gratefully received. Rory

Answer 1

I'm worried, however, that merging changes and following history may become difficult between branches in this model.

Well, you have decided you want to keep branches in separate clones and that doesn't come for free. But it's no a big trouble to set a repository level config file that aliases all the clones to ease pusing/pulling.

If programmers in our team make local clones of a branch, how do they backup the local clone? We're used to seeing svn commit messages like this on a feature branch "Interim commit: db function not yet working". I can't see a way of doing this easily in hg.

That's the number one reason actually to use a DVCS because it supports this use case perfectly. Commits are local until you push them . That means that every developer can create as much "interims" commits as he sees fit. BUT that is not a "backup" in the original sense, it's more like a "savepoint" for the individual developer. Until now you cluttered your history with those interims commits that got shared to all developers on your team. Using mercurial queues you can easily "fold" all those interims commits together before pushing them, leading to a clean history in your central repository.

If real backup (in the sense of: what happens if this dev machine catches fire) is a concern the answer is simple: Just give each developer a private server repository where he can regularly push to.