RFC: dealing with dead, anonymous feature branches

Martin Geisler mg at aragost.com
Sat May 8 03:48:47 CDT 2010


Matt Mackall <mpm at selenic.com> writes:

> On Fri, 2010-05-07 at 20:15 +0200, Martin Geisler wrote:
>>
>> If you're thinking of the synthetic merges mentioned above, then they
>> should be hidden so that nobody can resurrect them. You would only be
>> resurrect the heads that belong to the visible graph. Something like
>> this:
>> 
>> 
>>   [A] --- [B]
>>      \
>>       [X] --- <Y>
>>          \
>>           [Z]
>> 
>> 
>> If Z is closed ("killed"?) by W, then W and Y are merged by a hidden
>> dead merge changeset H:
>> 
>>   [A] --- [B]
>>      \
>>       [X] --- <Y> ---- <H>
>>          \            /
>>           [Z] --- <W>
>> 
>> The user can not see H, so he can only resurrect Y or W (by making a
>> child of Y or W). We will never merge H or other hidden changeset
>> into the visible graph, so I hope that means that the fake merge
>> happening in H wont affect the merges made with real, visible
>> changesets.
>
> Ahh, I had instead assumed that <Y> would merge with the tipmost
> closed head if one existed, so that we wouldn't add an extra commit
> each time. So your approach will work, but we add two commits each
> time we close a branch rather than one.

Right.

> Which suggests a third strategy: make the closing changeset itself
> hidden. But that has the side effect that you've now got no record of
> when, why, and by who a head was closed.

Yes, that's not very nice.

> And both approaches still introduce a completely new and not
> particularly Mercurial-like notion of "hidden changesets". Thinking
> about how those might be implemented and their side effects makes me
> nervous.

Me too, I think it would be a fairly invasive change. However, that last
paragraph about hidden merge changesets was not meant to be the
important part :-)

I'm imagining that a company would use this and once in a while they
would do this on their central server:

  hg push --also-dead-heads backup-repository
  hg clone . ../central-alive-only
  cd ..
  rm -r central
  mv central-alive-only central

That way the main repository would only have heads for the (named)
branches that are still in use. The developers could do the same if they
are bothered by their own heads.

I hope this is enough to make things workable without solving the
heads-are-bad problem up front. But I don't know how "bad" a head is for
the complexity. If it only becomes a problem with 50 heads, then I think
we're fine with the rotation scheme described above.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/


More information about the Mercurial-devel mailing list