Prevent unstable code going into default line

Question

Currently, I have 2 repository. One repository is named jstock, which contains all the stable source code.

Another repository named jstock-refactor-calendar-to-joda, which is cloned from jstock, and it contains all the unstable experimental feature code.

All the change-set in red rectangle is unstable experimental feature code. They are not finished yet. Hence, I do not have intent to make it merge with the change-set in green rectangle (Green rectangle indicates those are stable change-set)

After jstock-refactor-calendar-to-joda pulls from jstock, here is how it looks like.

Now, I would like to let the experimental code visible to jstock (But not going into default line, as they are unstable)

Hence, when I perform push from jstock-refactor-calendar-to-joda to jstock, here is what I get.

Now all unstable code are belongs to default line!

This not what I want. In jstock, I wish the stable code (in green rectangle) remains in default (left side), unstable code (in red rectangle) remains in right side. Note that, I do not want them to be merged yet, but I would like to have both development lines (stable and unstable) being visible.

Is there any step I had done wrong?

Answer 1

In this case you must have "force" pushed as you've created multiple heads. Both these heads are on the "default" branch. No problem with this as such but the issue you're worrying about is that your new head (with unstable code) is the "tip" of the default branch.

From the Mercurial FAQ:

The tip is always a head. If there are multiple heads in a repository, only one of them is the tip. Within a repository, changesets are numbered sequentially, so the tip has the highest sequence number. The word "tip" functions as a special tag to denote the tip changeset, and it can be used anywhere a changeset ID or tag is valid.

It would have been better to have pushed these changes to a named branch, as Lasse suggests, but you are where you are. In this case, you (or anyone pulling this repository for the first time) need to update the working copy to be on the stable part of your default branch.

hg update -r 12345

(where 12345 is the revision number of "Instead of limiting currency..."

For developers that already have this repository, when they pull your unstable changes they will see the multiple heads but their working copy won't automatically be updated to your new branch.

Answer 2

This was also posted on the Mercurial mailinglist and below is my reply:

The location of the two (anonymous) branches in the log viewer is not important: there is no left or right side, the order only depends on the order in which you have made the the pulls and pushes.

What you need is a way to label the changesets from the stable and unstable branches so that you can keep track of which is which. There are three main ways to do this:

• separate clones: This is the trivial way which you have already used where you keep a separate clone for the different branches.

  It has the advantage that you can throw away the changesets easily by just deleting the clone.

  It has the disadvantage that you don't really get a full overview of what is happening since the changesets are kept isolated.

• named branches: See my guide here if you haven't already done so:

  http://mercurial.aragost.com/kick-start/en/tasks/

  The advantage of named branches is that they put a label into each changeset so that you can track where they come from. If you have a named branch called 'refactor-calendar-to-joda', then you can do

  hg update refactor-calendar-to-joda
  

  in order to update the working copy to the tip of that branch. When new commits are made on the branch, the branch tip moves along, and so you can think of 'refactor-calendar-to-joda' as a floating tag.

  To get back to the default branch, you execute

   hg update default
  

  This is where the normal development ought to take place.

  Named branches are good for branches that are stable over longer time or where the name also makes sense years later. For example, if you use a bug tracker, then I suggest creating a bug to track the refactoring and then calling branch 'bug XX'. That way people can lookup the right bug number in the future.

• bookmarks: Bookmarks give names to changesets and as with named branches, you can update to a bookmark:

  hg update refactor-calendar-to-joda
  

  However, unlike named branches, the bookmarks live outside of the changeset graph. Because they are not part of the changesets themselves, bookmarks can be moved, deleted, renamed etc. You can push and pull bookmarks between repositories.

So use named branches for long-term persistent names, use bookmarks for short-lived branches, and use separate repositories if you like to have things separated.

Finally, see this guide for more on this topic:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 3

What you've done is perfectly fine. You have two heads on the same named branch 'default'. This is a completely normal way to work. Here's a pretty decent description of what's happening:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously

As Nick suggests, people who already have a clone will get the new head when they pull and people who newly clone will get both -- and that's just fine.

When people hg update default or just hg update they moved to the newest changeset on the default branch, so just do one more commit with the "Instead of limiting currency decimal places..." changeset as its parent like this:

hg update REVSION
...edit
hg commit

And they'll be automatically updated to the anonymous branch you want when they clone/update.

The thing to keep in mind is that mercurial existed for a long while before it had named branches, so everything you can do with named branches you can do with anonymous branches.

If you decide having two undifferentiated heads in that repo is too confusing consider giving bookmarks a look at. They're sticky labels that track the tips of anonymous branches -- more flexible than named branches in that they're not permanent.

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-bookmarks

Answer 4

In this case you probably should have waited with pushing, and make the whole repository available.

Or, when you started that branch, you should've given it a name. You can have multiple unnamed branches all belonging to the same named branch.

In other words, all of the changesets you're seeing there is part of the default branch, however the label is only shown for the tip of that branch. Since the new changesets are now the tip, that's where the label is shown in the UI.

If you had given it a name, default would've still been down on your tipmost changeset on the default branch.

To fix that, you would have to "replay" those changesets one by one. I don't know the best way to do that, but suffice to say they would get new hashes, so anyone that has pulled those changesets already risk pushing them back in as part of the default branch.