[PATCH] add support for marking changesets as dead
Matt Mackall
mpm at selenic.com
Tue Feb 1 21:50:35 UTC 2011
On Tue, 2011-02-01 at 14:52 -0600, Kevin Bullock wrote:
> On Feb 1, 2011, at 2:15 PM, Matt Mackall wrote:
>
> > There's no
> > good reasons for DAG pruning instruction to live in the DAG when we have
> > another channel available.
>
>
> Except that (and otherwise I track with your argument entirely) if the
> pruning instruction -isn't- in history, then how do you resolve the
> case when one clone has a branch marked as dead, and another clone has
> it live? Because I can bet that it'll also be reasonably common for
> people to want to resurrect [part of] a dead line of development.
> Would you disallow this entirely?
The markers in my scheme are fundamentally easy to move after the fact.
We could simply decide to emulate the proposed scheme's default of
invalidating dead markers when new descendant csets appear. Pseudo-code
for pull:
s = revset('dead1::')
pull(remote)
s2 = revset('dead1::')
if s != s2 and 'dead1' not in remote.keys('deadheads'):
# remote didn't know about dead1 and added new csets
delete dead1
warn("dropping dead1")
I'm not 100% sure this is the right behavior, but it's certainly doable.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list