Tue, 07 Mar 2017 16:27:32 -0800 rebase: move actual rebase into a single transaction
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 16:27:32 -0800] rev 31226
rebase: move actual rebase into a single transaction 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.
Tue, 07 Mar 2017 16:30:31 -0800 rebase: allow aborting if last-message.txt is missing
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 16:30:31 -0800] rev 31225
rebase: allow aborting if last-message.txt is missing Previously, if .hg/rebasestate existed but .hg/last-message.txt was missing, 'hg rebase --abort' would say there's no rebase in progress but 'hg checkout foo' would say 'abort: rebase in progress'. It turns out loading the collapse message will throw a "no rebase in progress" error if the file doesn't exist, even though .hg/rebasestate obviously indicates a rebase is in progress. The fix is to only throw an exception if we're trying to --continue, and to just eat the issues if we're doing --abort. This issue is exposed by us writing the rebase state earlier in the process. This will be used by later patches to ensure the user can appropriately 'hg rebase --abort' if there's a crash before the first the first commit has finished rebasing. Tests cover all of this. The only negative affect is we now require a hg rebase --abort in a very specific exception case, as shown in the test.
Tue, 07 Mar 2017 14:04:29 -0800 rebase: add storestatus support for transactions
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 14:04:29 -0800] rev 31224
rebase: add storestatus support for transactions This let's the status writing logic support transactions. This will be useful in a later patch where we add a transaction around the entire rebase.
Tue, 07 Mar 2017 14:11:44 -0800 rebase: move storestatus onto rebaseruntime
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 14:11:44 -0800] rev 31223
rebase: move storestatus onto rebaseruntime The rebaseruntime class already has the restorestatus function, so let's make it own the store status function too. This get's rid of a lot of unnecessary argument passing and will make a future patch cleaner that refactors storestatus to support transactions.
Tue, 07 Mar 2017 14:19:08 -0800 rebase: clear updatestate during rebase --abort in more cases
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 14:19:08 -0800] rev 31222
rebase: clear updatestate during rebase --abort in more cases Previously, rebase --abort would only call update if you were on a node that had already been rebased. This meant that if the rebase failed during the rebase of the first commit, the working copy would be left dirty (with a .hg/updatestate file) and rebase --abort would not have update to clean it up. The fix is to also perform an update if you're still on the target node or on the original working copy node (since the working copy may be dirty, we still need to do the update). We don't want to perform an update in all cases though because of issue4009. A subsequent patch makes this case much more common, since it causes the entire rebase transaction to rollback during unexpected exceptions. This causes the existing test-rebase-abort.t to cover this case.
Wed, 08 Mar 2017 00:49:15 +0530 repoview: convert attribute names to unicodes on Python 3
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 08 Mar 2017 00:49:15 +0530] rev 31221
repoview: convert attribute names to unicodes on Python 3 In Python 3, the attribute names must be strings i.e. unicodes.
Wed, 08 Mar 2017 00:45:19 +0530 parsers: alias long to int on Python 3
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 08 Mar 2017 00:45:19 +0530] rev 31220
parsers: alias long to int on Python 3
Wed, 08 Mar 2017 00:40:15 +0530 store: slice over a bytestring to get characters instead of ascii values
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 08 Mar 2017 00:40:15 +0530] rev 31219
store: slice over a bytestring to get characters instead of ascii values On Python 2, >>> a = b'abc' >>> a[1] 'b' Whereas on python 3, >>> a = b'abc' >>> a[1] 98 >>> a[1:2] b'b' This does not change behaviour on python 2.
Thu, 02 Mar 2017 13:27:42 +0100 vfs: use 'vfs' module directly in 'mercurial.hg'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:27:42 +0100] rev 31218
vfs: use 'vfs' module directly in 'mercurial.hg' Now that the 'vfs' classes moved in their own module, lets use the new module directly. We update code iteratively to help with possible bisect needs in the future.
Wed, 01 Mar 2017 11:00:12 +0100 vfs: extract 'vfs' class and related code to a new 'vfs' module (API)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 01 Mar 2017 11:00:12 +0100] rev 31217
vfs: extract 'vfs' class and related code to a new 'vfs' module (API) The 'scmutil' is growing large (1500+ lines) and 2/5 of it is related to vfs. We extract the 'vfs' related code in its own module get both module back to a better scale and clearer contents. We keep all the references available in 'scmutil' for now as many reference needs to be updated.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip