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

[Greg Ward]

On Sun, Nov 22, 2009 at 12:05 PM, Matt Mackall <mpm at selenic.com> wrote:
>>   * 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"
>
> It's easy enough to do this by catching exceptions in commit(). The
> rollback code should not need to know about commit messages.

Oh yeah, right, of course.  OK, I've just sent new patches for issue
1635 that work like this.

>>   * 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)
>
> Doesn't seem like a good complexity/performance trade-off to me, given
> that rollback is not supposed to be a common operation.

...until you have a control-freak jerk (like me) enforcing policy in a
pretxncommit hook.  Then you'll get a rollback every time your commit
message references a bad bug ID, or you create a filename with spaces
in it, or you commit source code with trailing whitespace, or a file
with lines longer than 100 chars, ... whatever the local policy is
that's enforced in a hook.

IOW, workflows where there is more central control (like in a company,
rather than an open-source project) might be more prone to fascist
hooks and therefore more prone to rollback.

> Looking closer at destroyed(), I think it's a bad idea. Cache-building
> should be lazy. When we invalidate, we should just nuke the caches and
> wait until someone actually wants them again to rebuild them.

Sounds great until you have 100k changesets in your repo.  Then it
takes ~30 sec to rebuild the branch head cache after a rollback,
because the whole cache gets invalidated.

It also takes me ~8-10 sec to rebuild the tag cache in my big repo,
although ISTR that rollback does not invalidate the whole tag cache,
thankfully.

Combine "frequent rollbacks due to fascist hooks" with "30 sec to
rebuild branch head cache after a rollback", and I fear unhappy users.
 Them: "I thought you said Mercurial was going to be faster than CVS!"
 Me: "Ummm... errr... ahhh...".

Greg