[PATCH 2 of 2] rollback: only restore dirstate (et. al.) when appropriate

[Greg Ward]

On Fri, Sep 16, 2011 at 3:42 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2011-09-15 at 22:22 -0400, Greg Ward wrote:
>> # HG changeset patch
>> # User Greg Ward <greg at gerg.ca>
>> # Date 1316139696 14400
>> # Node ID b33ba776a9977a4b1460eebb5acd9dc954da03c5
>> # Parent  23fe96275fabc99c33f61da305f81948ea5c61df
>> rollback: only restore dirstate (et. al.) when appropriate.
[...]
>> This is very preliminary, just posted for initial review. Some tests
>> still fail.
>
>
>> +            oldlen = int(oldlen)
>> +            oldtip = oldlen - 1
>> +            doomed = range(oldlen, len(self))
>
> I think it would be better to simply truncate history and then see if
> the working directory parent has vanished rather than looking at the
> may-not-be-present-or-correct transaction description.

Hmmmmm, yeah, I see your point. But I was hoping to take advantage of
the 'doomed' list to extend localrepository.destroyed() a bit, kinda
like this:

--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -1212,12 +1212,12 @@
                 tr.release()
             lock.release()

-    def destroyed(self):
+    def destroyed(self, nodes=None):
         '''Inform the repository that nodes have been destroyed.
         Intended for use by strip and rollback, so there's a common
-        place for anything that has to be done after destroying history.'''
-        # XXX it might be nice if we could take the list of destroyed
-        # nodes, but I don't see an easy way for rollback() to do that
+        place for anything that has to be done after destroying history.
+        nodes is the list of destroyed node IDs, or None if not known.
+        '''

         # Ensure the persistent tag cache is updated.  Doing it now
         # means that the tag cache only has to worry about destroyed


That opens the door to a meaningful 'destroyed' hook, and I think
makes it possible to do less damage when invalidating the tag or
branch head caches. I had vague ideas about this back when I
implemented the tag cache ... and now I find myself with an
opportunity to follow up on that!

However, extending destroyed() is orthogonal to the task at hand. I'll
see about a more robust check for whether the working parent is
affected.

Greg