effective use of in-repository branching

[Matt Mackall]

On Wed, Feb 07, 2007 at 12:39:19PM -0800, Stuart Marks wrote:
> Some colleagues and I have been discussing the use of Mercurial's 
> named-branch feature to keep patches and mainline development in the same 
> repository. Named branches seem almost ideal for doing this, but there are 
> a couple stumbling blocks.
> 
> For example, suppose we have the following sequence of revisions:
> 
> 81----82(1.0)----83----84(tip)
> 
> Let's say that rev 82 corresponds to a 1.0 release of the project, so it 
> was tagged as such. Post-1.0 development continues with revs 83, 84, and so 
> on.
> 
> Now let's say that we need to issue a patch for 1.0 but we don't want to 
> mix in the work-in-progress from revs 83 and 84. We'd update a working copy 
> to rev 82, implement the patch, and commit it with a new branch name. This 
> would result in:
> 
> 81----82(1.0)----83----84
>         |
>         |
>         +----85[1.0patch](tip)
> 
> Structurally, this is perfectly correct. However, there are some things 
> about the situation now that seem quite inconvenient.
> 
> (1) Common usage is for developers to do "pull -u" to keep up to date with 
> a shared repository. Unfortunately, this updates to the tip, which is now 
> on a branch. If a developer's repo is at rev 83, then "pull -u" will now 
> result in something like:
> 
> abort: update spans branches, use 'hg merge' or 'hg update -C' to lose 
> changes
> 
> This is proper behavior, since we don't want to switch branches 
> automatically. However, it forces the developer to update manually, which 
> undermines the usefulness of "pull -u".
> 
> Instead of updating to the tip, maybe update and pull -u should 
> automatically update to the most recent head of the current branch, 
> something like "hg update $(hg branch)". If we have to give the mainline an 
> explicit branch name, that would be OK. I note that the BranchPlan wiki 
> page has the following item:
> 
>    * if a branch is set, update should update to the tip of the current 
>    branch
> 
> Does this mean the same thing as I said? If so, then consider this my vote 
> for this feature.

Yep, that's what that is.

If someone wants to take a stab at this, it should be pretty easy.
 
> (2) Returning to the state of the repository as diagrammed above, suppose a 
> developer creates a new repository with clone or pull and then dives into 
> development. This is a mistake, since the tip is on the patch branch 
> instead of on the mainline.
> 
> We can work around this by telling everyone to make sure to run "hg update 
> -C mainline" before beginning work. Or, we can tell everyone who pushes 
> changes to make sure that their last commit leaves the tip at the end of 
> the mainline. Either seems quite troublesome.
> 
> It seems that the root cause of these problems is that several hg 
> operations default to using the tip, but the tip can bounce around from 
> branch to branch. It would be nice if there were a way to modify hg to 
> update to something else instead of to the tip.
> 
> This was discussed a bit last month; see the mail archives for January 2007 
> and look for messages with the subject "Needs for a default branch". 
> Unfortunately some of the proposals were quite heavyweight, and the thread 
> didn't seem to reach any reasonable conclusion.

What's needed here is a solution that doesn't change the behavior for
people working without named branches, as that is still the
recommended way to do things.

> It seems to me that a very lightweight notion of "default branch" would be 
> useful. I guess this would be stored in .hg/hgrc. It would have the 
> following semantics:
> 
> a) Cloning a repo would propagate the default branch (if any) into the new 
> repo, and then update to the default branch (if any), otherwise to the tip.

We currently don't have any mechanism for transmitting info that's not
"checked in". And I'd like to avoid adding one, as it would mean
having to re-solve a large set of problems. So the .hg/hgrc thing
doesn't really work.

I also don't really like the idea of having a hard-coded name like "HEAD"
or "default" that's the default for clone operations.

One possibility would be to piggyback on the tags capability: to set
the name of the default branch, you tag a revision in that branch
"default-branch". But that's really ugly.

So we may just want to do the fixed name thing. If there's a branch
marked "default" (or whatever name), we use it. Otherwise, use tip.

-- 
Mathematics is the supreme nostalgia of our time.