effective use of in-repository branching

[Stuart Marks]

[multiple responses inline]

Matt Mackall wrote:
 > On Wed, Feb 07, 2007 at 12:39:19PM -0800, Stuart Marks wrote:
 >> 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.

Great. I haven't done any development on hg itself so I don't think this one is 
for me. Is there something else I can do, like file a bug? I might be able to 
help out with doc, too. As far as I can see the branching model is documented 
pretty sparsely. I had to do a fair bit of experimentation in order to 
understand it.

 > 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.

Oh yes, I see.

 > 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.

I understand the objection to having a fixed name, but I guess having a fixed 
name is preferable to not having this behavior at all.

Matt Mackall wrote:
 > On Wed, Feb 07, 2007 at 06:48:09PM -0500, Jesse Keating wrote:
 >> Why can't the 'default' branch be the unnamed branch, or a branch of name ''.
 >> That way named branches have to be explicitly accessed by name, otherwise you
 >> just get ''.
 >
 > It's a possibility. One current problem here is that the branch cache
 > currently ignores ''. But I believe Thomas has a fix for that.

This would be OK with me, but it does represent a change in the current 
behavior. It would update to the most recent head of the unnamed branch instead 
of to the tip. Some might consider this to be too incompatible.

Christian Boos wrote:
> Another option would be to simply abort the update in case of ambiguity.
> 
> $ hg update
> abort: multiple branches found, specify one of:
> (here goes the output of 'hg heads --template 
> "{branches}\t\t{rev}:{node|short}"')
> 
> The old behavior would still be available by calling explicitly 'hg 
> update tip'.

This isn't too different from what it does now. What I (and apparently others) 
are after is a notion of a default branch that's defined in such a way that 
updates go to the "right" head automatically. If update aborts because of 
ambiguity, this forces the user to do a little bit of figuring and to update 
manually. In some sense this isn't much of a big deal. But little things like 
this make the difference between having a tool that's merely useful vs. one 
that works so smoothly that users don't have to think about it anymore.

Georg-W. Koltermann wrote:
 > Note that the default branch may need to be different for different
 > people.  After all, branches are about separating development streams,
 > so one group may work on branch A, another one on branch B.
 >
 > In light of this I think having the default branch specified in .hg/hgrc
 > is still a good idea.  The default branch should not be transmitted
 > anyways, everyone will need to pick her or his own, just like the
 > default push and default pull and stuff.

Right, the default branch will differ for different people or even between 
different repos being used by the same person. However, I'm not sure that 
.hg/hgrc is the right place or is even necessary.

In most cases the working copy will have a parent rev. The behavior of update 
in this case should be to update to the most recent head of the branch of the 
parent rev. I don't think .hg/hgrc should be consulted in these cases. The 
current state of the working copy establishes the context well enough, I think.

The only cases remaining occur when the working copy has no parent, that is, 
after an init and a pull, or during a clone, which has to choose some rev to 
update to initially. Here, the "default branch" value is used just once, and 
thereafter it's governed by the parent of the working copy. I think it's 
important to find some way to establish the initial value of the default 
branch. But since the initial value is used just once, it doesn't really make 
sense to read some value from .hg/hgrc.

(At least, I think this case only occurs once during the lifetime of a repo. 
Once the working copy has a parent, is it ever possible for it to return to a 
state where it has no parent? I couldn't find any.)

solo turn wrote:
 > here seems to be the before mentioned thread:
 > http://www.opensolaris.org/jive/thread.jspa?threadID=23554

Yup, that's it. I didn't mention it directly because it has digressions of its 
own plus some discussion of OpenSolaris-specific issues. But people might find 
it interesting. Note also that I don't work on OpenSolaris, but instead of Java 
ME (another Sun open-source effort) so I have yet again different viewpoint 
from the OpenSolaris folks.

s'marks