Mercurial Workflow for small team

Question

I'm working in a team of 3 developers and we have recently switched from CVS to Mercurial. We are using Mercurial by having local repositories on each of our workstations and pulling/pushing to a development server. I'm not sure this is the best workflow, as it is easy to forget to Push after a Commit, and 3 way merge conflicts can cause a real headache. Is there a better workflow we could use, as I think the complexity of distributed VC is outweighing the benefits at the moment.

Thanks

Answer 1

If you are running into a lot of 3 way merges it might be because you have too much overlap in what you and your team members are working on. Mercurial is pretty good at handling merges itself, so long as you all aren't editing the exact same lines of a file. If possible, you could divide up the work more clearly and avoid some of the headaches of large merges. Also note that this would still be a problem with CVS since it's arguably worse at merging than mercurial.

You also don't need to push after every commit. Your workflow could look something like this:

• Commit part of some feature.
• Commit some more of some feature.
• Commit last part of feature.
• Commit bug fixes for stupid mistakes.
• Push full feature to repo.

To an extent, this looks like Going Dark, but that can be alleviated by making sure that the features in the above example are smallish in scope.

Answer 2

1. Forget all you know about CVS. Mercurial is nothing like it even if some commands feel somewhat similar.

2. Read http://hginit.com/. Follow the examples.

3. Forget all you know about CVS.

4. I mean it. This is the hardest part. Learn to trust your tool.

Answer 3

It sounds like you're all making your changes to the same branch. This has the unsatisfying side-effect that you're merging each others' changes on almost every single commit, which would be fine except that manually intervening for conflicts isn't something you want to do every time you push.

Here's the workflow I would suggest. The idea is to use branching more heavily, so you need to merge to the master branch less often.

1. Have every developer develop every feature in a separate branch. This way:

   • you avoid constantly merging changes from other people, and

   • you are free of the pressure to push incomplete work before the next guy, "makes it hard to merge."

2. When a feature is "done" and if the changes would appear to apply cleanly (a judgement call), merge the feature branch directly into the master branch and delete the feature branch.

3. If a feature falls way behind the master branch (many features merged), or if the merge otherwise appears difficult:

   1. merge master into the feature branch.

   2. Find and fix any bugs in contented isolation from other developers.

   3. Assuming the feature is ready to go, merge it into master (notice: now the merge in this direction will be clean by definition). If not, you can just continue developing.