Fri, 15 Nov 2013 23:28:43 -0500 discovery: stop using nodemap for membership testing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 15 Nov 2013 23:28:43 -0500] rev 20225
discovery: stop using nodemap for membership testing Nodemap is not aware of filtering so we need to ask the changelog itself if a node is known. This is probably a bit slower but such check does not dominated discovery time. This is necessary if we want to run discovery on filtered repo.
Fri, 15 Nov 2013 23:27:39 -0500 discovery: enforce filtering into revlogbaseddag._internalizeall
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 15 Nov 2013 23:27:39 -0500] rev 20224
discovery: enforce filtering into revlogbaseddag._internalizeall One more step toward discovery running on filtered repo.
Fri, 15 Nov 2013 23:27:15 -0500 discovery: make revlogdag work on filtered repo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 15 Nov 2013 23:27:15 -0500] rev 20223
discovery: make revlogdag work on filtered repo The revlogdag class is a core part of discovery. We need its initialisation to exclude revision filtered out.
Sat, 16 Nov 2013 11:53:44 -0500 pull: run findcommon incoming on unfiltered repo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 16 Nov 2013 11:53:44 -0500] rev 20222
pull: run findcommon incoming on unfiltered repo The discovery is not yet ready for filtered repo. Pull was using filtered for its discovery which is wrong. It worked by dumb luck because discovery mainly use funtion that does not respect the filtering. Trying to makes discovery work on filtered repo revealed this bug.
Tue, 05 Nov 2013 18:37:44 +0100 push: more robust check for bundle fast path
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 05 Nov 2013 18:37:44 +0100] rev 20221
push: more robust check for bundle fast path When all changesets in the local repo are either being pushed or remotly known, we can take a fast path when bundling changeset because we are certain all local deltas are computed againts base known remotely. So we have a check to detect this situation, when we did a bare push and nothing was excluded. In a coming refactoring, the discovery will run on filtered view and the content of `outgoing.excluded` will just include unserved (secret) changeset not filtered by the repoview used to call push (usually "visible"). So we need to check if there is both no excluded changeset and nothing filtered by the current repoview.
Sat, 16 Nov 2013 15:36:50 -0500 pull: fix post-pull common computation
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 16 Nov 2013 15:36:50 -0500] rev 20220
pull: fix post-pull common computation Before that changes, pulled revision that happend to be already known locally (so, not actually added) was not taken into account when computing the new common set between local and remote. It appears that we already know the heads of the pulled set. It is in the `rheads` variable, so we are just using it and everything is works fine. We are dropping the, now useless, computation of `added` set in the process.
Mon, 25 Nov 2013 22:00:46 +0100 run-tests: better check for python version
Simon Heimberg <simohe@besonet.ch> [Mon, 25 Nov 2013 22:00:46 +0100] rev 20219
run-tests: better check for python version Compare version by using pythons tuple comparison. So we do not match on python 3.0 or newer.
Mon, 23 Dec 2013 14:14:31 +0100 templatekw: allow tagtypes other than global in getlatesttags
Andrew Shadura <andrew@shadura.me> [Mon, 23 Dec 2013 14:14:31 +0100] rev 20218
templatekw: allow tagtypes other than global in getlatesttags hg-git uses tagtype 'git', for example, so it's better to check for tagtype != 'local', not strictly for 'global'
Tue, 26 Nov 2013 12:58:27 -0800 revlog: move file writing to a separate function
Durham Goode <durham@fb.com> [Tue, 26 Nov 2013 12:58:27 -0800] rev 20217
revlog: move file writing to a separate function Moves the code that actually writes to a file to a separate function in revlog.py. This allows extensions to intercept and use the data being written to disk. For example, an extension might want to replicate these writes elsewhere. When cloning the Mercurial repo on /dev/shm with --pull, I see about a 0.3% perf change. It goes from 28.2 to 28.3 seconds.
Sun, 24 Nov 2013 17:33:39 -0600 discovery: prefer loop to double-for list comprehension in changegroupsubset
Kevin Bullock <kbullock@ringworld.org> [Sun, 24 Nov 2013 17:33:39 -0600] rev 20216
discovery: prefer loop to double-for list comprehension in changegroupsubset The double-for form of list comprehensions gets particularly unreadable when you throw in an 'if' condition. This expands the only remaining instance of the double-for syntax in our codebase into a loop.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip