Fri, 25 Sep 2015 17:18:28 -0400 manifest: rename treemanifest load functions to ease debugging
Augie Fackler <augie@google.com> [Fri, 25 Sep 2015 17:18:28 -0400] rev 26401
manifest: rename treemanifest load functions to ease debugging I'm hunting an infinite recursion bug at the moment, and having both of these methods named just _load is muddying the waters slightly.
Fri, 25 Sep 2015 17:17:36 -0400 manifest: add id(self) to treemanifest __repr__
Augie Fackler <augie@google.com> [Fri, 25 Sep 2015 17:17:36 -0400] rev 26400
manifest: add id(self) to treemanifest __repr__ Also rename __str__ to __repr__ since that's what we really want for pdb.
Mon, 28 Sep 2015 10:27:36 -0700 bundlerepo: let bundle repo look in the _mancache
Durham Goode <durham@fb.com> [Mon, 28 Sep 2015 10:27:36 -0700] rev 26399
bundlerepo: let bundle repo look in the _mancache When looking up a base revision, we were ignoring the contents that were already available in the manifest's _mancache. This patch allows us to use that data instead of reading from the revlog. This is useful in our pushrebase extension (which allows rebasing on the server side during a push) because it allows us to prefetch the bundle base manifest before aquiring the repo lock (1 second saving), which means doing less work inside the lock, which means a 20% higher commit rate.
Sun, 27 Sep 2015 22:19:54 +0900 check-seclevel: wrap entry point by function
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Sep 2015 22:19:54 +0900] rev 26398
check-seclevel: wrap entry point by function This is intended to narrow scope of local variables. The global _verbose flag will be replaced later by ui.verbose.
Sun, 27 Sep 2015 22:16:24 +0900 check-seclevel: set executable bit as it has shebang
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Sep 2015 22:16:24 +0900] rev 26397
check-seclevel: set executable bit as it has shebang
Wed, 23 Sep 2015 12:56:05 -0700 bundle20: extract core payload generation in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 23 Sep 2015 12:56:05 -0700] rev 26396
bundle20: extract core payload generation in its own function We are about to allow compressing the core of the bundle2. So we extract the generation of this bits in its own parts to make this compression phases easier in a later changesets.
Wed, 23 Sep 2015 14:00:16 -0700 unbundle20: allow registering handlers for stream level parameters
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 23 Sep 2015 14:00:16 -0700] rev 26395
unbundle20: allow registering handlers for stream level parameters As a comment in the code have been asking for, it is now possible to register piece of code that handle parameters for the stream. I've been wondering is such function should be class methods or not. I eventually went for externally decorated methods to stick with the culture of extensibility from an extensions that apply to bundle2.
Wed, 23 Sep 2015 11:55:27 -0700 bundle2: allow to specify unsupported value on error
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 23 Sep 2015 11:55:27 -0700] rev 26394
bundle2: allow to specify unsupported value on error A client may support an argument but not some of its values (eg: coming "compression" parameters). We allow this case to be carried in the exception.
Wed, 23 Sep 2015 11:44:52 -0700 bundle2: rename error exception class for unsupported feature
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 23 Sep 2015 11:44:52 -0700] rev 26393
bundle2: rename error exception class for unsupported feature The original name explicitly mention "Part", however it is also used outside of parts related feature. We rename from 'UnsupportedPartError' to 'BundleUnknownFeatureError' to fix this.
Wed, 23 Sep 2015 11:33:30 -0700 changegroup: use a different compression key for BZ in HG10
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 23 Sep 2015 11:33:30 -0700] rev 26392
changegroup: use a different compression key for BZ in HG10 For "space saving", bundle1 "strip" the first two bytes of the BZ stream since they always are 'BZ'. So the current code boostrap the uncompressor with 'BZ'. This hack is impractical in more generic case so we move it in a dedicated "decompression".
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip