Branches in general

[Matt Mackall]

On Sat, Jun 09, 2007 at 12:08:37AM -0400, Daniel Holth wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Eric M. Hopper wrote:
> > On Fri, 2007-06-08 at 20:19 -0700, Brendan Cully wrote:
> >> As you know, I also have my doubts about hg's branches, but I'd be
> >> curious to know what the specific drawbacks were, and how current the
> >> implementation was. Most of the UI work to make branches halfway
> >> reasonable happened after 0.9.3 was released. Some of it is only a few
> >> days old...
> >
> > *nod*  I would like to post more details, but I'm hampered by the fact
> > that it was a private email and I'm not sure how much I can ethically
> > reveal.  :-)
> Eh, I didn't want to hurt anybody's feelings and I wasn't sure how to
> rewrite the post. We have 36 branches in "hg branches". They are not
> very useful, most of them only containing two or three revisions, and
> it's likely that you can't merge the branch anyway because it descend
> from another branch of a few revisions. It seems highly unlikely that
> "hg update -r branchname" would take me anywhere useful.

I don't get it. It'll take you to that branch? If you don't know a
priori what branch you want, then you've got a namespace management
problem.

> So I try to only pay attention to the DAG.
> 
> I'm not convinced that the current branch implementation can express
> what I would prefer which is basically  the way that git does it, go
> play with it if you don't remember (each branch is a pointer to a
> single head, but in Mercurial they'd probably be pointers to a
> collection of heads [usually 1]).

About the only salient difference that I can see between the git
approach and the Mercurial approach is that Mercurial's is
version-controlled. That is, we remember what branch each changeset
was on when it was committed. Git simply knows where the last commit
was (which Mercurial deduces).

Is the problem simply that Mercurial remembers and reports branches
that are no longer relevant? That we in fact have too much information?

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

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

> The way that Subversion does branches is also better: you can't append
> trunk -- branch -- trunk without doing some kind of merge operation.

I have no idea what that means.
 
> We might be talking again about where Mercurial misses its design
> assumptions. Sure, you can copy the 650 MB clone, and we even have the
> disk space to do so, but I'm surely not going to do that (5 minutes)
> when I can attempt to update back to "deployed" (10 seconds) and make
> another revision. Unfortunately, since "being in a different
> in-repository DAG branch" does not obscure any of the other 8 heads,
> things get very confusing.
> 
> Also notice that we basically don't use hardlinks because we have a
> central "official" repository over http which is very close to the
> deployed revision (and not owned by the developer's user in any case
> if local), and we haven't written some horrendous "find a checkout the
> dev already has ; clone -r
> some-revision-ancestor-of-official-repository-tip; pull from official
> repository"

I've no idea what you're getting at here either. Let's back up to the
beginning, please, and get a picture of what the core problem is.

> Speaking of "after 0.9.3 was released", how about we tag hg-stable and
> call it 0.9.4, and tag hg-devel and call it 0.9.5? A friend and I
> would be willing to help with any "summarize the changelog" work, and
> perhaps with dpkg.

Tip will be released as 0.9.4. The current stable branch will be
discarded and a new one will be created.

-- 
Mathematics is the supreme nostalgia of our time.