Branches in general

Daniel Holth dholth at fastmail.fm
Sat Jun 9 18:52:50 CDT 2007


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

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"

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

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"

It's nice to know the history of when a particular revision was pulled
into Matt's hg-stable branch, something that Mercurial loses at the
moment, but I'm not convinced this history should be automatically
propagated whenever hg-stable is cloned.
>> 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

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

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.

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

iD8DBQFGaz1RVh4W2pVfoMsRAjiSAKCE3GUdzeGwg0Yzw2KtiZal4UVEywCfWpiy
/k5Hc+cMdWV5wRlkQFBvBWI=
=lKtd
-----END PGP SIGNATURE-----



More information about the Mercurial-devel mailing list