Saving info about each transaction (was Re: [PATCH 2 of 2] rollback: tell the user their previous commit message was saved)

[Greg Ward]

[original patch description]
> rollback: tell the user their previous commit message was saved
> (issue1635)

[Matt's response]
> I don't think this is the right place for this message as it'll be shown
> for unrelated rollbacks.

I've been thinking about this.  The problem is that we don't know,
after the fact, what the last transaction committed.  Was it a pull?
push? unbundle? commit?  No way to know.

But that is a solvable problem.  And it opens the door to solving
another problem that has bugged me for a while, namely "what
changesets are being destroyed by this rollback?".  Here's the idea:

  * modify the transaction class to track two things: the nature of
the transaction
     (pull, push, unbundle, commit) and its contents (list of changeset IDs)
  * when committing the transaction, write that info to .hg/txninfo
  * modify every bit of code that opens and commits a transaction to
supply this
     information (only 5-6 places in current hg-crew)
  * make that information available at rollback time

Obviously, there's a lot of code out there in the world that needs to
continue to work, so changes to the transaction class have to be done
in a backwards-compatible way: add new methods, or optional args to
__init__() and/or close().  And we have to be able to handle
transactions that don't have .hg/txninfo at all.

But this feature would enable several nifty things:

  * at rollback time, we would know if we were rolling back a single commit,
    so could intelligently say "last commit message saved in .hg/message"
  * in localrepository.destroyed(), we could know which nodes are being
    destroyed, which should make it possible to invalidate less of the branch
    head cache (and maybe less of the tag cache too, although it is less
    dramatically affected by destroying nodes)
  * likewise, it would make it possible to add a meaningful "destroy" hook that
    gets called after nodes have been destroyed (and possibly "predestroy" too,
    although "pretxndestroy" is obviously impossible)

What do you think?  If people like this idea, I will keep the "save
.hg/message" patch and drop the "tell user about .hg/message" patch
for the time being, and do it right later.

Greg