This is an archive of the discontinued Mercurial Phabricator instance.

rebase: add config to move rebase into a single transaction
AbandonedPublic

Authored by durham on Jul 12 2017, 1:56 PM.

Details

Reviewers
martinvonz
phillco
Group Reviewers
Restricted Project
Summary

This was previously landed as cf8ad0e6c0e4 but backed out in a5abaa81fa because
it broke hook mid rebase and caused conflict resolution data loss in the event
of unexpected exceptions. This new version adds the behavior back but behind a
config flag, since the performance improvement is notable in large repositories.

The next patch adds a test covering this config.

The old commit message was:

Previously, rebasing would open several transaction over the course of rebasing
several commits. Opening a transaction can have notable overhead (like copying
the dirstate) which can add up when rebasing many commits.

This patch adds a single large transaction around the actual commit rebase
operation, with a catch for intervention which serializes the current state if
we need to drop back to the terminal for user intervention. Amazingly, almost
all the tests seem to pass.

On large repos with large working copies, this can speed up rebasing 7 commits
by 25%. I'd expect the percentage to be a bit larger for rebasing even more
commits.

There are minor test changes because we're rolling back the entire transaction
during unexpected exceptions instead of just stopping mid-rebase, so there's no
more backup bundle. It also leave an unknown file in the working copy, since our
clean up 'hg update' doesn't delete unknown files.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

durham created this revision.Jul 12 2017, 1:56 PM
durham added reviewers: Restricted Project, martinvonz.Jul 12 2017, 1:58 PM

lgtm

mercurial/util.py
592–594

Thanks, I was looking for something like this on one of my branches!

phillco accepted this revision as: phillco.Jul 12 2017, 3:51 PM

Actual LGTM.

Though, it's interesting, it looks like I have the ability to accept as hg. I presume I'll need to keep unchecking that so I don't accidentally pretend to be a core reviewer.

This revision is now accepted and ready to land.Jul 12 2017, 3:51 PM
martinvonz accepted this revision.Jul 12 2017, 4:16 PM
martinvonz added inline comments.
mercurial/util.py
592

The body looks more like a "nulltransaction" (I think close(), release(), abort() are part of transaction's interface), but this is fine with me anyway.

martinvonz added inline comments.Jul 12 2017, 4:54 PM
hgext/rebase.py
721

Won't this and tr's context manager together double-close the transaction?

durham added inline comments.Jul 13 2017, 5:22 PM
hgext/rebase.py
721

The context manage will only call tr.release(),since it's an exception exit path.

In D62#790, @phillco wrote:

Though, it's interesting, it looks like I have the ability to accept as hg. I presume I'll need to keep unchecking that so I don't accidentally pretend to be a core reviewer.

Anyone can accept as #hg, but only reviewers can accept as hg-reviewers, which is a blocking reviewer on all new diffs (but not this one because it was created before that herald rule was added I think)

martinvonz added inline comments.Jul 13 2017, 6:26 PM
hgext/rebase.py
721

Ah, right.

Anyway, once D66 is in, you should be able to simplify this to:

tr = None
if singletr = ui.configbool('rebase', 'singletransaction'):
    tr = repo.transaction('rebase')
with util.acceptintervention(tr):
    rbsrt._performrebase(tr)

So it seems best to wait for that to land.

durham abandoned this revision.Jul 18 2017, 11:14 AM

Update sent as https://phab.mercurial-scm.org/D135 . Not sure how to get it to update this diff instead, so abandoning.