Branches in general

Daniel Holth dholth at fastmail.fm
Sat Jun 9 04:08:37 UTC 2007


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

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

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

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"

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.

- - Daniel H.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGaifFVh4W2pVfoMsRAjDXAJ4kKk/Mvbg+km4DBfp1NhoN7YDbwgCgwZlK
/q9XEbXpN3VPyXEK74Q06oU=
=csXw
-----END PGP SIGNATURE-----




More information about the Mercurial-devel mailing list