Branches in general

[Matt Mackall]

On Sat, Jun 09, 2007 at 07:52:50PM -0400, Daniel Holth wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Matt Mackall wrote:
> >
> > Is the problem simply that Mercurial remembers and reports branches
> > that are no longer relevant? That we in fact have too much information?
> That is a problem. Too much output from "hg branches", and when I am
> in a particular branch, "hg log", "heads", "glog" etc shows
> information from every branch.
> >> For example, I would like a branch
> >> that's "the currently deployed revision", it would be easy to copy the
> >> branch and start working on a spelling correction.
> >
> > How is this not 'hg co -C release' and edit?
> "The currently deployed revision" happens when someone types: "hg
> update -C rev" in the deployment location. By default nothing has been
> committed to the history to mention this. Now rev and all its
> ancestors are in the "released" branch. This does somewhat work with a
> clone that always has its tip as what's released.

Ok, that's a little bit different from a more traditional software
practice. There's not a whole lot of value in tagging such deployments.
But there is some sense in having a branch that represents "things
that have been or are going to be deployed". That can either be
"default" or "deployed". Let's call it "deployed" for now.
 
> This might happen 10 times in a day as we update our website. Maybe
> I'm confusing in-repository branches with tags, or maybe before we
> release any revision we should commit a new revision on top of it with
> the branch name "released". At the moment the correct thing to do is
> either "hg update -C $(wget -o stdout
> http://released/repository?cmd=heads)" or "hg clone
> http://released/repository target"

So in the named branch scheme, you do either:

 hg pull http://central/repository#deployed
 hg update -C deployed

or

 hg clone http://central/repository#deployed

The latter will check out the deployed branch by default and future
pulls will pull only the deployed branch as well.

> > Boggle. Your currently deployed revision isn't tagged and on a release
> > branch?
> 
> Maybe we should and we may try that, but I'm worried about merging the
> numerous tag commits. For example, I notice that the current tip of
> http://selenic.com/mercurial/hg-stable is not tagged, but we can
> easily fix that. We can put a "changegroup" hook in the repository,
> and every time someone pushes a new changegroup we tag it because we
> don't want to lose the history of when changes made it into the
> official stable repository. So what if the developer's repository
> looks like this:
> 
> stable1 -> stable2 -> stable3 -> barn

Groan. I spent a while trying to figure out what the hell you meant by
barn.

> We push stable1 into an empty stable repository, because we'd like to
> do a few more tests on stable2 and stable3.
> 
> The changegroup hook goes to work so that we don't lose the history of
> when a change became part of a classic Mercurial repository-branch.
> The stable repository looks like this.
> 
> stable1 -> tag stable1 message: "Released at the crack of dawn on
> Thursday"
> 
> stable2 is ready.
> 
> stable1 -> tag stable1
> stable1 > tag stable2 -> stable2
> 
> At some point somebody decides to pull from stable and it says "you
> have 2914 heads", or maybe we would merge "tag stable2" into "stable2"
> and then push, so that we did not have to use "push -f"

Or you could simply have a separate tag branch. But all that tagging
is excessive, IMO.

> >> In this way, I
> >> don't have to a) store "the currently deployed revision" (20 bytes of
> >> information) in a 650 megabyte clone, or b) look it up with "heads" on
> >> a remote repository. It is easier not to make the
> >> series-of-branches-in-a-linear-history mistake, because new branches
> >> can be copied from the "incoming" branch.
> >
> > You haven't defined what that mistake is.
> That mistake is when you write this history:
> 
> default -> fix1 -> fix2 -> fix3 -> default
> 
> instead of:
> 
> default -> default
> default -> fix1
> default -> fix2
> default -> fix3
> 
> To release fix1:
> 
> hg update default; hg merge fix1; hg commit

I see.
 
> > So you created a naming scheme without considering that those names
> > would be around forever? Not surprisingly, that doesn't work out well.
> > A branch name like release-fixes might have done better.
> We created the scheme without knowing that the names would be around
> forever because we could not find it documented, and we expected that
> they would expire from the output of "hg branches" somehow. But how
> does it help me to have fewer branch names? I could have "released"
> and "not-released", but then if I put it all together in a single
> repository I have 35 heads instead of 35 branch names.

Long-lived names for branches of 1 or 2 revisions is a bit excessive.
Eric's "active" filter might help a bit here. It will only show branch
heads that have never been merged into other branches.

> I think I will enjoy the proposed localbranches (more than one
> repository per working copy) functionality, coupled with an easy way
> to use "the tip of some other repository" as a revision id in diff /
> merge etc.

I'm not opposed to having an "hg branch -l" command that works like
"hg tag -l". And yes, there is value to being able to look up things
like remote tags, branches, and tip on remote repos. The functionality
exists in the protocol, we just haven't thought of a command for it.

-- 
Mathematics is the supreme nostalgia of our time.