Fri, 03 Mar 2017 13:32:10 -0500 extensions: use [0:1] slice on config path instead of [0]
Augie Fackler <raf@durin42.com> [Fri, 03 Mar 2017 13:32:10 -0500] rev 31264
extensions: use [0:1] slice on config path instead of [0] This behaves the same in Python 2 and Python 3, even though the path is a bytes.
Fri, 03 Mar 2017 13:27:21 -0500 extensions: use inspect module instead of func_code.co_argcount
Augie Fackler <raf@durin42.com> [Fri, 03 Mar 2017 13:27:21 -0500] rev 31263
extensions: use inspect module instead of func_code.co_argcount Fixes the extsetup argspec check on Python 3.
Tue, 07 Mar 2017 18:29:58 -0800 treemanifest: add tests covering hg diff of partial trees
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 18:29:58 -0800] rev 31262
treemanifest: add tests covering hg diff of partial trees Previously the hg files tests also covered the logic (i.e. treemanifest.matches) that governed how hg diff limited its diff. In a future patch we will be switching treemanifest.diff() to have a custom implementation, so let's go ahead and add equivalent test coverage for hg diff.
Tue, 07 Mar 2017 17:52:45 -0800 context: remove uses of manifest.matches
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 17:52:45 -0800] rev 31261
context: remove uses of manifest.matches This removes the uses of manifest.matches in context.py in favor of the new manifest.diff(match) api. This is part of removing manifest.matches since it is O(manifest). To drop the dependency on ctx._manifestmatches(s) we transfer responsibilty for creating status oriented manifests over to ctx._buildstatusmanifest(s). This already existed for workingctx, we just need to implement a simple version for basectx. The old _manifestmatches functionality is basically identical to the _buildstatusmanifest functionality (minus the matching part), so no behavior should be lost.
Tue, 07 Mar 2017 17:49:50 -0800 context: remove assumptions about manifest creation during _buildstatus
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 17:49:50 -0800] rev 31260
context: remove assumptions about manifest creation during _buildstatus Previously we called self.manifest() in some cases to preload the first manifest. This relied on the assumption that the later _manifestmatches() call did not duplicate any work the original self.manifest() call did. Let's remove that assumption, since it bit me during my refactors of this area and is easy to remove.
Tue, 07 Mar 2017 17:56:30 -0800 context: move _manifest from committablectx to workingctx
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 17:56:30 -0800] rev 31259
context: move _manifest from committablectx to workingctx committablectx had a _manifest implementation that was only used by the derived workingctx class. The other derived versions, like memctx and metadataonlyctx, define their own _manifest functions. Let's move the function down to workingctx, and let's break it into two parts, the _manifest part that reads from self._status, and the part that actually builds the new manifest. This separation will let us reuse the builder code in a future patch to answer _buildstatus with varying status inputs, since workingctx has special behavior for _buildstatus that the other ctx's don't have.
Tue, 07 Mar 2017 09:56:11 -0800 status: handle more node indicators in buildstatus
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 09:56:11 -0800] rev 31258
status: handle more node indicators in buildstatus There are several different node markers that indicate different working copy states. The context._buildstatus function was only handling one of them, and this patch makes it handle all of them (falling back to file content comparisons when in one of these states). This affects a future patch where we get rid of context._manifestmatches as part of getting rid of manifest.matches(). context._manifestmatches is currently hacky in that it uses the newnodeid for all added and modified files, which is why the current newnodeid check is sufficient. When we get rid of this function and use the normal manifest.diff function, we start to see the other indicators in the nodes, so they need to be handled or else the tests fail.
Tue, 07 Mar 2017 18:38:20 -0800 merge: remove uses of manifest.matches
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 18:38:20 -0800] rev 31257
merge: remove uses of manifest.matches This gets rid of the manifest.matches calls in merge.py in favor of the new api. This is part of getting rid of manifest.matches since it is O(manifest).
Tue, 07 Mar 2017 09:56:11 -0800 copies: remove use of manifest.matches
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 09:56:11 -0800] rev 31256
copies: remove use of manifest.matches Convert the existing use of manifest.matches to use the new api. This is part of getting rid of manifest.matches, since it is O(manifest).
Tue, 07 Mar 2017 09:56:11 -0800 manifest: add match argument to diff and filesnotin
Durham Goode <durham@fb.com> [Tue, 07 Mar 2017 09:56:11 -0800] rev 31255
manifest: add match argument to diff and filesnotin As part of removing manifest.matches (since it is O(manifest)), let's start by adding match arguments to diff and filesnotin. As we'll see in later patches, these are the only flows that actually use matchers, so by moving the matching into the actual functions, other manifest implementations can make more efficient algorithsm. For instance, this will allow treemanifest diff's to only iterate over the files that are different AND meet the match criteria. No consumers are changed in this patches, but the code is fairly easy to verify visually. Future patches will convert consumers to use it. One test was affected because it did not use the kwargs version of the clean parameter.
Thu, 09 Mar 2017 00:07:13 +0900 fileset: drop false function signatures from revs() and status() docs
Yuya Nishihara <yuya@tcha.org> [Thu, 09 Mar 2017 00:07:13 +0900] rev 31254
fileset: drop false function signatures from revs() and status() docs They should be inserted by @predicate helper.
Wed, 08 Mar 2017 22:30:12 +0900 py3: factor out bytechr() function
Yuya Nishihara <yuya@tcha.org> [Wed, 08 Mar 2017 22:30:12 +0900] rev 31253
py3: factor out bytechr() function I also changed xrange(127) to range(127) as the number is relatively small.
Thu, 02 Mar 2017 13:34:01 +0100 vfs: use 'vfs' module directly in 'test-clone-uncompressed'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:34:01 +0100] rev 31252
vfs: use 'vfs' module directly in 'test-clone-uncompressed' 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.
Thu, 02 Mar 2017 13:33:28 +0100 vfs: use 'vfs' module directly in 'test-filecache'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:33:28 +0100] rev 31251
vfs: use 'vfs' module directly in 'test-filecache' 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.
Thu, 02 Mar 2017 13:33:16 +0100 vfs: use 'vfs' module directly in 'test-parseindex'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:33:16 +0100] rev 31250
vfs: use 'vfs' module directly in 'test-parseindex' 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.
Thu, 02 Mar 2017 13:33:02 +0100 vfs: use 'vfs' module directly in 'test-lock'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:33:02 +0100] rev 31249
vfs: use 'vfs' module directly in 'test-lock' 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.
Thu, 02 Mar 2017 13:32:49 +0100 vfs: use 'vfs' module directly in 'contrib/undumprevlog'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:32:49 +0100] rev 31248
vfs: use 'vfs' module directly in 'contrib/undumprevlog' 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.
Thu, 02 Mar 2017 13:32:27 +0100 vfs: use 'vfs' module directly in 'hgext.largefile'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:32:27 +0100] rev 31247
vfs: use 'vfs' module directly in 'hgext.largefile' 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.
Thu, 02 Mar 2017 13:32:14 +0100 vfs: use 'vfs' module directly in 'hgext.convert'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:32:14 +0100] rev 31246
vfs: use 'vfs' module directly in 'hgext.convert' 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.
Thu, 02 Mar 2017 13:31:39 +0100 vfs: use 'vfs' module directly in 'hgext.transplant'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:31:39 +0100] rev 31245
vfs: use 'vfs' module directly in 'hgext.transplant' 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.
Thu, 02 Mar 2017 13:31:32 +0100 vfs: use 'vfs' module directly in 'hgext.shelve'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:31:32 +0100] rev 31244
vfs: use 'vfs' module directly in 'hgext.shelve' 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.
Thu, 02 Mar 2017 13:31:23 +0100 vfs: use 'vfs' module directly in 'hgext.mq'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:31:23 +0100] rev 31243
vfs: use 'vfs' module directly in 'hgext.mq' 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.
Thu, 02 Mar 2017 14:49:50 +0100 vfs: use 'vfs' module directly in 'mercurial.unionrepo'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 14:49:50 +0100] rev 31242
vfs: use 'vfs' module directly in 'mercurial.unionrepo' 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.
Thu, 02 Mar 2017 14:49:01 +0100 vfs: use 'vfs' module directly in 'mercurial.statichttprepo'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 14:49:01 +0100] rev 31241
vfs: use 'vfs' module directly in 'mercurial.statichttprepo' 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.
Thu, 02 Mar 2017 14:47:03 +0100 vfs: use 'vfs' module directly in 'mercurial.bundlerepo'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 14:47:03 +0100] rev 31240
vfs: use 'vfs' module directly in 'mercurial.bundlerepo' 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.
Thu, 02 Mar 2017 13:31:07 +0100 vfs: use 'vfs' module directly in 'mercurial.debugcommand'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:31:07 +0100] rev 31239
vfs: use 'vfs' module directly in 'mercurial.debugcommand' 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.
Thu, 02 Mar 2017 13:30:58 +0100 vfs: use 'vfs' module directly in 'mercurial.simplemerge'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:58 +0100] rev 31238
vfs: use 'vfs' module directly in 'mercurial.simplemerge' 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.
Thu, 02 Mar 2017 13:30:47 +0100 vfs: use 'vfs' module directly in 'mercurial.cmdutil'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:47 +0100] rev 31237
vfs: use 'vfs' module directly in 'mercurial.cmdutil' 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.
Thu, 02 Mar 2017 13:30:38 +0100 vfs: use 'vfs' module directly in 'mercurial.subrepo'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:38 +0100] rev 31236
vfs: use 'vfs' module directly in 'mercurial.subrepo' 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.
Thu, 02 Mar 2017 13:30:28 +0100 vfs: use 'vfs' module directly in 'mercurial.archival'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 02 Mar 2017 13:30:28 +0100] rev 31235
vfs: use 'vfs' module directly in 'mercurial.archival' 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.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip