Tue, 20 Jul 2010 20:37:29 +0530 mq: cleanup status if applied mq is stripped (issue1881) stable
Vishakh H <vsh426@gmail.com> [Tue, 20 Jul 2010 20:37:29 +0530] rev 11637
mq: cleanup status if applied mq is stripped (issue1881) stripping of applied mq patches leads to wrong state recorded in status file. find all mq patches that will be affected and clean up status file before strip.
Tue, 20 Jul 2010 18:29:00 +0900 bundle: lookup revisions after addbranchrevs stable
Nicolas Dumazet <nicdumz.commits@gmail.com> [Tue, 20 Jul 2010 18:29:00 +0900] rev 11636
bundle: lookup revisions after addbranchrevs When addbranchrevs extends revs, it adds changeset hashes, and not node ids. Which means that we have to lookup for revisions _after_ the addbranchrevs call, instead of before.
Tue, 20 Jul 2010 14:42:05 +0900 log: do not redefine cachefunc in walkchangerevs
Nicolas Dumazet <nicdumz.commits@gmail.com> [Tue, 20 Jul 2010 14:42:05 +0900] rev 11635
log: do not redefine cachefunc in walkchangerevs The same variable is defined a few blocks earlier. The first phases in walkchangerevs should in fact fill that cache, and allow faster lookups in the last phase. Redefining and overriding this cached function, (knowing that it will be called with the same arguments) defeats the caching purpose.
Wed, 21 Jul 2010 09:43:45 +0200 cmdutils: fix code style
Martin Geisler <mg@aragost.com> [Wed, 21 Jul 2010 09:43:45 +0200] rev 11634
cmdutils: fix code style
Tue, 20 Jul 2010 23:29:49 +0530 contrib: add debugshell extension
Vishakh H <vsh426@gmail.com> [Tue, 20 Jul 2010 23:29:49 +0530] rev 11633
contrib: add debugshell extension
Tue, 20 Jul 2010 14:32:33 +0900 log: document the different phases in walkchangerevs
Nicolas Dumazet <nicdumz.commits@gmail.com> [Tue, 20 Jul 2010 14:32:33 +0900] rev 11632
log: document the different phases in walkchangerevs
Tue, 20 Jul 2010 14:13:33 +0900 log: slowpath: only walk specified revision range during preparation
Nicolas Dumazet <nicdumz.commits@gmail.com> [Tue, 20 Jul 2010 14:13:33 +0900] rev 11631
log: slowpath: only walk specified revision range during preparation Even with --removed, it does not make sense to examine changesets outside of the revision range that was specified by the user: the last phase only yields a subset of (revs), preparation phase hence only has to examine (revs) to fill correctly fncache.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip