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

Suggestion: also examine git.

With any distributed version control system like hg or git, your local copy of the repo contains both the working files and the local repository. That may be all the backup you want. If you need more, simply copy the files (including the repo files in the .hg or .git directory) to your backup location.

Answer 2

I can't speak to your svn branch migration problem. Your solution sounds ok, but concurrency is VERY VERY HARD, and I haven't thought about your situation well enough to say.

But assuming you do make a separate repository on the server for each "svn-branch", then I believe you can solve your second problem very easily. First, follow Peter Loron's advice by copying the files to do work. Then, whenever a developer is ready to commit to "our team's server based repository"* then they can commit, just as an "hg-branch": within the same same repository. You'll get the same kind of commits of "Interim commit: db function not yet working" but they won't be on the trunk screwing up everyone's build.

The key to all of this working, and the reason hg/git are so cool, is that when the feature is ACTUALLY DONE, you merge that "hg-branch" it back into the trunk within the same repository, and chances are far better than with SVN that the automated merge will JUST WORK.

Answer 3

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.

Answer 4

If you need a lot of concurrent development, you need to use a distributed version control system, ClearCase, or Perforce. ClearCase and Perforce don't do distributed version control, but they do handle merges probably better than most other tools out there.

ClearCase's merge is made for concurrent development and works extremely well. In fact, most developers in ClearCase develop on their own branch, then merge their changes into the integration stream when what they're working on is complete. The UCM layer on top of ClearCase simply automates this behavior.

Perforce's merging is more tuned to what they call divergent branching, but it seems to handle concurrent development okay.

Subversion is a nice version control system. I use it a lot, and you can't beat the price, but let's face it, merging in Subversion is still very, very rough around the edges. The use of properties to track merging is very hackish. When you look at logs, you see lots of changes simply due to Subversion changing the svn:merge property even though the files were basically unaffected. Plus, you must know when to use the --reintegrate flag.

Of course, distributed version control systems handle concurrent development with aplomb. It's the way they were designed from the start.

My only question is why are you doing so much concurrent development? Over the years, I've found forcing developers to work together on the same set of changes simply works the best. When forced to work on the same set of code, developers are more careful with their development. They take smaller bites, are more careful about changes, and communicate more with each other.

When I was working with developers in ClearCase, and each developer had their own branch, I use to go around and make sure developers were merging in their changes on a regular basis. It is so much easier to program when no one, but you is changing the code. Developers would simply do all their work on their branch without every getting the changes the other developers had made. You have 20 developers all doing this, and you see no changes on the main branch. Then right before we had a delivery, the developers would then make massive merges of all their changes. Hilarity ensued.

We would spend the next week trying to clean everything up and getting all of the developer's changes to work together. QA was upset because they had almost no time for testing. It wasn't uncommon to send the release out untested. After all, we had deadlines to meet.

There are good reasons to have concurrent development, but I've found many times it is the developers who request it because it makes their job easier. They don't have to coordinate their changes because it is now your job. After all, that's why they pay you the big money.

Well, not the really big money, but you're paid more than a lot of people. Maybe not the developers, but you make more than other people at your company like the janitor -- unless he belongs to a union. Well, you get stock options.