A Guide to Branching in Mercurial

[Martin Geisler]

"Alexander Schatten" <ml_alexanderschatten at gmx.at> writes:

>> http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
> Thanks for this article, good to read;
>
> I have, however, one question: as far as my limited understanding of
> branches goes, there is (opposed to one of the comments) a significant
> difference in how merges are treatet.
>
> (1) When you just make an anonymous branch by updating to an older
> version and committing, then e.g. go back to the default branch and
> hit “hg merge” the anonymous and default branche are merged without
> further ado

Right. Anonymous branches are normally short-lived and so it should be
easy to merge them. The typical case is when you work along and pull
From a server where others have pushed things in the mean time: you now
have two small anonymous branches. A simple 'hg merge' is all it takes
to merge them.

If you instead try to just push your code to the server, you will get
the 'push creates multiple heads' error. This is a hint that you should
merge and then push. If you push the extra head (with --force), it may
be confusing for other people to decide which head they should -- after
all, the heads are unnamed.

Another reason for merging before push is that it is a bit impolite to
leave the work of merging to others: if you introduced new code that
needs to be merged, it often makes most sense that you do the work.

But notice that Mercurial (in constrast to a system like SVN) makes it
very easy for you to say: "I give up on this merge, please help!". You
simply push the multi-headed repository somewhere and a collegue can
then pull, merge and push.

> (2) If you create named branches, and again, hit “hg merge” nothing
> happens. That means: named branches are not merged "by default".
>
> I hope I make myself clear. Is that correct, or do I get something
> wrong?

No, I think you got it right. At a basic level, named branches are
branches in the same way as anonymous branches: they represent divergent
lines of development. However, since they are named, they are treated as
longer-lived objects. That is why you must be explicit when you want to
merge them. It also makes more sense to create multiple heads by pushing
a named branch -- people should know within the project what each named
branch means.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090904/f46535bb/attachment.pgp