Using Mercurial local clones for branched development?

Question

I'm an ex SVN user trying to work out the best way to do branched development in hg. My project is fairly new currently has no branches. A friend of mine suggested that making a local clone of the repos. then working in that was better than using a named branch.

So if I use this model, would the workflow be:

• [say original project has been cloned to be in c:\projects\sk\tracker]
• hg clone https:[url of repos] tracker_featurex [to be issued from c:\projects\sk]
• change to subdir tracker_featurex
• checkin and push as per normal
• [optional, how do I pull changes from the main repos. into this one?]
• [final step, how do I get changes from this clone back into the main trunk?]

I need help on whether this workflow is correct and what the exact commands would be for the two steps in the [] braces.

Thanks a great deal to anyone who can help, Fred

Answer 1

I would recommend you take a look at Steve Losh's post on branching in Mercurial: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

He goes over various types of branches (clones, bookmarks, named branches, anonymous branches) as well as the commands you would run for each. There are pros and cons to all of them. Local clones are ok if you are the only developer but they are not as useful in a workflow where more than one developer needs to work on a branch. The claim that clones are universally better than named branches is a myth. You should find a branching model that fits your workflow.

Update:

If you do want to do local clones you can move you changes using hg push from the new workspace (Assuming you have a Projects folder and a repo named test):

Projects> hg clone test test-new-feature
Projects> cd test-new-feature
Projects/test-new-feature> <do some work>
Projects/test-new-feature> hg commit -m "Work is done."
Projects/test> <Might need a pull/merge here>
Projects/test-new-feature> hg push

If there are changes in the test repo you need to pull/merge them before pushing.

You can also hg pull from the original workspace:

Projects> hg clone test test-new-feature
Projects> cd test-new-feature
Projects/test-new-feature> <do some work>
Projects/test-new-feature> hg commit -m "Work is done."
Projects/test-new-feature> cd ../test
Projects/test> hg pull ../test-new-feature

This might create multiple heads in the test repo and you would need to merge/commit.

Projects/test> hg merge
Projects/test> hg commit -m "Merged in new-feature."

Either are good options. I might recommend pulling rather than pushing. The main difference to me is the location of the merge step. I think pulling from the feature repo makes the history a little more readable.

Answer 2

making a local clone of the repos. then working in that was better than using a named branch.

Overly dramatic and ambitious statement in common. When you clone-per-feature, you have only one branch (named branch) per repo, but nothing more (practically, briefly speaking).

When feature is finished, you have to "push to parent"|"pull from clone" in order to return changes back. At this stage, if some work was done in parent repo after clone, anonymous branch will appear (+1 head) and merge is a must (same as for work in named brach in one repo), but, it named brach can tells something fast later (you use good names, isn't it?), anonymous branch tells almost nothing without additional tricks (bookmarks, f.e). Part of my repo below as example of work in clone with intermediate pulls and must-merges after pulls/ (sorry, russian commit-messages) and even I can't recall now, why I had repo cloned for editorials - maybe I just play with Clones-Workflow

Answer 3

I am fledgling to Hg, so take what I say with a word of caution :-)

I love having named branches, but use them very judiciously! There are downsides to the approach I use below, but it works well for my current environment which is a small shop. I don't mind preserving history forever and I'm not concerned with reducing the number of commits (but Mq/record/etc can address this latter bit).

This is how I use branches in the code I work on:

1. Default branch.
   • This is built on the build server.
   • This should only have one head.
   • This should always compile.
   • This should always be the "best effort" at completing bugs/features.
2. "Workbench" branch.
   • This can have multiple heads.
   • Anonymous branches are encouraged. Shared bookmarks used to "name" active anonymous branches.
   • The state should be almost always compilable, but it is not a requirement.
   • Represents "work in progress".

Okay, so this is what my process might look like this: (I've excluded pull/push/merge-theirs steps).

1. I get a bug report in.
2. I switch to "workbench" tip (or whatever revision is appropriate).
3. I fix the bug, possibly committing several times. (I really should learn to use queues or record, etc.)
4. (If I am interrupted in the above process, e.g. have to work on a different bug, or am otherwise side-tracked I will create a new head above where #2, or as appropriate. I may give the current anonymous branch tip a name with a bookmark, or I may not.)
5. Once complete, I merge the relevant branch/changes into "default" and hopefully the build server still loves me :-)

I think the best thing to do is forget about how branches in SVN worked. They are not liked named branches at all and anyone who says otherwise is latching onto the fact they both have "names" and not much more. Every branch in Hg is part of a "named branch" (that is, has a name associated with it, be it "default" or "workbench" or otherwise). But it doesn't matter, except for organization: a branch is a branch and it doesn't matter if it's referring to the "tip" of an anonymous branch or the tip of the only head (really an anonymous branch itself) in a named branch.

Try a few things, use what works best :)