Tue, 13 Oct 2015 10:57:54 -0700 exchange: refactor bundle specification parsing
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 10:57:54 -0700] rev 26640
exchange: refactor bundle specification parsing The old code was tailored to `hg bundle` usage and not appropriate for use as a general API, which clone bundles will require. The code has been rewritten to make it more generally suitable. We introduce dedicated error types to represent invalid and unsupported bundle specifications. The reason we need dedicated error types (rather than error.Abort) is because clone bundles will want to catch these exception as part of filtering entries. We don't want to swallow error.Abort on principle.
Tue, 13 Oct 2015 11:43:21 -0700 exchange: move bundle specification parsing from cmdutil
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 11:43:21 -0700] rev 26639
exchange: move bundle specification parsing from cmdutil Clone bundles require a well-defined string to specify the type of bundle that is listed so clients can filter compatible file types. The `hg bundle` command and cmdutil.parsebundletype() already establish the beginnings of a bundle specification format. As part of formalizing this format specification so it can be used by clone bundles, we move the specification parsing bits verbatim to exchange.py, which is a more suitable place than cmdutil.py. A subsequent patch will refactor this code to make it more appropriate as a general API.
Tue, 24 Mar 2015 00:28:28 +0900 revset: add optional offset argument to limit() predicate
Yuya Nishihara <yuya@tcha.org> [Tue, 24 Mar 2015 00:28:28 +0900] rev 26638
revset: add optional offset argument to limit() predicate It's common for GUI or web frontend to fetch chunk of revisions per batch size. Previously it was possible only if revisions were sorted by revision number. $ hg log -r 'limit({revspec} & :{last_known}, 101)' So this patch introduces a general way to retrieve chunk of revisions after skipping offset revisions. $ hg log -r 'limit({revspec}, 100, {last_count})' This is a dumb implementation. We can optimize it for baseset and spanset later.
Mon, 12 Oct 2015 17:19:22 +0900 revset: port limit() to support keyword arguments
Yuya Nishihara <yuya@tcha.org> [Mon, 12 Oct 2015 17:19:22 +0900] rev 26637
revset: port limit() to support keyword arguments The next patch will introduce the third 'offset' argument. This allows us to specify 'offset' without 'n' argument.
Mon, 12 Oct 2015 17:14:47 +0900 revset: eliminate temporary reference to subset in limit() and last()
Yuya Nishihara <yuya@tcha.org> [Mon, 12 Oct 2015 17:14:47 +0900] rev 26636
revset: eliminate temporary reference to subset in limit() and last()
Wed, 14 Oct 2015 02:49:17 +0900 dirstate: read from pending file under HG_PENDING mode if it exists
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 14 Oct 2015 02:49:17 +0900] rev 26635
dirstate: read from pending file under HG_PENDING mode if it exists True/False value of '_pendingmode' means whether 'dirstate.pending' is used to initialize own '_map' and so on. When it is None, neither 'dirstate' nor 'dirstate.pending' is read in yet. This is used to keep consistent view between '_pl()' and '_read()'. Once '_pendingmode' is determined by reading one of 'dirstate' or 'dirstate.pending' in, '_pendingmode' is kept even if 'invalidate()' is invoked. This should be reasonable, because: - effective 'invalidate()' invocation should occur only in wlock scope, and - wlock can't be gotten under HG_PENDING mode '_trypending()' is defined as a normal function to factor similar code path (in bookmarks and phases) out in the future easily.
Wed, 14 Oct 2015 02:49:17 +0900 dirstate: make writing in-memory changes aware of transaction activity
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 14 Oct 2015 02:49:17 +0900] rev 26634
dirstate: make writing in-memory changes aware of transaction activity This patch delays writing in-memory changes out, if transaction is running. '_getfsnow()' is defined as a function, to hook it easily for ambiguous timestamp tests (see also fakedirstatewritetime.py) 'if tr:' code path in this patch is still disabled at this revision, because there is no client invoking 'dirstate.write()' with repo object. BTW, this patch changes 'dirstate.invalidate()' semantics around 'dirstate.write()' in a transaction scope: before: with repo.transaction(): dirstate.CHANGE('A') dirstate.write() # change for A is written out here dirstate.CHANGE('B') dirstate.invalidate() # discards only change for B after: with repo.transaction(): dirstate.CHANGE('A') dirstate.write() # change for A is still kept in memory dirstate.CHANGE('B') dirstate.invalidate() # discards changes for A and B Fortunately, there is no code path expecting the former, at least, in Mercurial itself, because 'dirstateguard' was introduced to remove such 'dirstate.invalidate()'.
Wed, 14 Oct 2015 02:49:17 +0900 dirstate: make functions for backup aware of transaction activity
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 14 Oct 2015 02:49:17 +0900] rev 26633
dirstate: make functions for backup aware of transaction activity Some comments in this patch assume that subsequent patch changes 'dirstate.write()' like as below: def write(self, repo): if not self._dirty: return tr = repo.currenttransaction() if tr: tr.addfilegenerator('dirstate', (self._filename,), self._writedirstate, location='plain') return # omit actual writing out st = self._opener('dirstate', "w", atomictemp=True) self._writedirstate(st) This patch makes '_savebackup()' write in-memory changes out, and it causes clearing 'self._dirty'. If dirstate isn't changed after '_savebackup()', subsequent 'dirstate.write()' never invokes 'tr.addfilegenerator()' because 'not self._dirty' is true. Then, 'tr.writepending()' unintentionally returns False, if there is no other (e.g. changelog) changes pending, even though dirstate changes are already written out at '_savebackup()'. To avoid such situation, this patch makes '_savebackup()' explicitly invoke 'tr.addfilegenerator()', if transaction is running. '_savebackup()' should get awareness of transaction before 'write()', because the former depends on the behavior of the latter before this patch.
Wed, 14 Oct 2015 02:49:17 +0900 dirstate: move code paths for backup from dirstateguard to dirstate
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 14 Oct 2015 02:49:17 +0900] rev 26632
dirstate: move code paths for backup from dirstateguard to dirstate This can centralize the logic to write in-memory changes out correctly according to transaction activity into dirstate. Passing 'repo' object to newly added functions is needed to examine current transaction activity in subsequent patches, because 'dirstate' itself doesn't have direct reference to it.
Tue, 13 Oct 2015 12:25:43 -0700 localrepo: restore dirstate to one before rollbacking if not parent-gone
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 13 Oct 2015 12:25:43 -0700] rev 26631
localrepo: restore dirstate to one before rollbacking if not parent-gone 'localrepository.rollback()' explicilty restores dirstate, only if at least one of current parents of the working directory is removed at rollbacking (a.k.a "parent-gone"). After DirstateTransactionPlan, 'dirstate.write()' will cause marking '.hg/dirstate' as a file to be restored at rollbacking. https://mercurial.selenic.com/wiki/DirstateTransactionPlan Then, 'transaction.rollback()' restores '.hg/dirstate' regardless of parents of the working directory at that time, and this causes unexpected dirstate changes if not "parent-gone" (e.g. "hg update" to another branch after "hg commit" or so, then "hg rollback"). To avoid such situation, this patch restores dirstate to one before rollbacking if not "parent-gone". before: b1. restore dirstate explicitly, if "parent-gone" after: a1. save dirstate before actual rollbacking via dirstateguard a2. restore dirstate via 'transaction.rollback()' a3. if "parent-gone" - discard backup (a1) - restore dirstate from 'undo.dirstate' a4. otherwise, restore dirstate from backup (a1) Even though restoring dirstate at (a3) after (a2) seems redundant, this patch keeps this existing code path, because: - it isn't ensured that 'dirstate.write()' was invoked at least once while transaction running If not, '.hg/dirstate' isn't restored at (a2). In addition to it, rude 3rd party extension invoking 'dirstate.write()' without 'repo' while transaction running (see subsequent patches for detail) may break consistency of a file backup-ed by transaction. - this patch mainly focuses on changes for DirstateTransactionPlan Restoring dirstate at (a3) itself should be cheaper enough than rollbacking itself. Redundancy will be removed in next step. Newly added test is almost meaningless at this point. It will be used to detect regression while implementing delayed dirstate write out.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip