Mercurial - how to push unfinished branches?

Question

We converted everything to Mercurial coming from CVS and so far so good. An issue we encountered today though is this situation.

Before the move to Mercurial I had a few pending changes from a while back, features that were started and later postponed for various reason. Odds are that someone else will finish those features months from now picking up from where I left off.

After cloning the new Mercurial repository I created separate branches to isolate those features.

It left me with something like this (made up rev. number)

hg update default
hg branch feature1
hg commit -m "Description of what I was doing in feature1"
hg update default 
hg branch feature2
hg commit -m "Description of what I was doing feature2" (my tip is now here)
hg update default
hg push -f (to force the creation of my new branches, w/o affecting default, I haven't merged them)

During this the team have been working and pushing to our central repository so the default branch is say rev 40 (tip)

Now my push -f worked fine but positioned (tip) to my latest change -> 50:feature3 (tip). I was expecting the tip to stay at default on the central repository and just have my branches in there for someone to pick them up whenever. The graph also looks pretty funny when I use hgwebdir so I am pretty sure that's the wrong approach.

How would I do this? Should I close the branch first? Is tip actually important or just meta-data.

Answer 1

tip is always the most recent changeset added to the repository. From hg help revs:

The reserved name "tip" is a special tag that always identifies the most recent revision.

So long as the head of the default branch is what you expect, you'll be OK. No need to close the branch (but it's better to use hg push --new-branch if your version of Mercurial is new enough to support it).

Answer 2

tip is just an automatically-applied label referring to (I think) the most recent commit. Not a big deal; it's just there for convenience.

Answer 3

The tip label is pure meta-data and always points to the changeset with the highest revision number -- there is no more logic than that.

However, the fact that tip now points to a changeset on the feature branch wont cause you any trouble. When people make a clone, they will automatically be updated to the tip-most changeset on the default branch. So they can begin working right away after a clone. Furthermore, people who already have a clone will stay on their named branch when they run hg update. Here hg update takes you to the tip-most changeset on that named branch, e.g., on default if that is where you started.

People may think that hg update tip is the same as hg update, but that is only when there are no named branches at play. With named branches, giving an explicit revision name such as tip can changeset your named branch -- a plain hg update cannot.