[PATCH] add support for marking changesets as dead

Matt Mackall mpm at selenic.com
Tue Feb 1 14:15:37 CST 2011


On Tue, 2011-02-01 at 11:21 +0100, Martin Geisler wrote:
> > And that, I think, is conceptually broken. I can know that I want "1
> > and descendants" dead long before I know what I want to replace it
> > with. Having to commit an extra dummy cset (note that we actively
> > reject empty csets!) to have a living head at this point "sucks" from
> > a user POV.
> 
> Sort of -- see it this way: the dead changesets are no good if you want
> to back up a linear track of development. They are good if you have
> different (concurrent!) lines of development and you want to kill one of
> them, in which case you already have a branch point in the past.

I want to focus on just one issue for a bit: your choice of direction.
Your proposal is about "the set of heads x and all its _ancestors_ that
are not ancestors of heads not in x". That's not exactly a simple rule.
In revset notation, it'd be something like '::dead() and not ::(heads()
and not dead())'. And if I want to prune back to something that's not a
branch point, I'm forced to introduce dummy changesets. 

My proposed approach is "the set of changesets x and all their
_descendants_" with no additional caveats ('dead()::' in revset-speak). 
Not only is this conceptually simpler, it allows you to precisely prune
a line of development at any point without adding additional changesets.

So, is this pruning to non-branch-points a real issue? My contention is
yes. First, 'branch points' are not an easily identified thing in
Mercurial, short of poking around at graph views. We don't have a simple
way of asking 'what is the first ancestor of x that's only ancestral to
x' without doing something like the big revset expression above. 

Second, it's going to be common for people to want to back out only a
portion of changesets after a branchpoint: "my first 5 changesets were
fine, but the last 5 I pushed were broken".

Third, people are also going to want to mark things discarded well
before they're ready to commit anything new: "I need to throw out the
junk that moron Bob committed on the stable branch today but I'm not
planning to commit anything else there until an actual fix for stable
shows up".

As far as I can see, you've latched onto the ancestors direction because
it's the obvious way to do thing when you've chosen to store the pruning
markers as new commits, but aside from that, it's not a good choice.
Given the constraint that everything is communicated in history, it
might be the right answer, but that constraint doesn't apply. There's no
good reasons for DAG pruning instruction to live in the DAG when we have
another channel available.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list