Tue, 15 Jul 2014 14:49:45 -0700 match: use util.re.compile instead of util.compilere
Siddharth Agarwal <sid0@fb.com> [Tue, 15 Jul 2014 14:49:45 -0700] rev 21909
match: use util.re.compile instead of util.compilere
Tue, 15 Jul 2014 14:40:43 -0700 util: move compilere to a class
Siddharth Agarwal <sid0@fb.com> [Tue, 15 Jul 2014 14:40:43 -0700] rev 21908
util: move compilere to a class We do this to allow us to use descriptors for other related methods. For now, util.compilere does the same thing. Upcoming patches will remove it.
Tue, 15 Jul 2014 14:35:19 -0700 util: rename 're' to 'remod'
Siddharth Agarwal <sid0@fb.com> [Tue, 15 Jul 2014 14:35:19 -0700] rev 21907
util: rename 're' to 'remod' Upcoming patches will introduce a binding called 're'.
Wed, 02 Jul 2014 15:47:39 +0200 bundle2-push: drop _pushbundle2extraparts
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 15:47:39 +0200] rev 21906
bundle2-push: drop _pushbundle2extraparts All core user are now using the new way. We drop the old way.
Wed, 02 Jul 2014 16:10:14 +0200 bundle2-test: use the new way to extend push content
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 16:10:14 +0200] rev 21905
bundle2-test: use the new way to extend push content The only core user of the old way were tests. We update them.
Wed, 02 Jul 2014 15:26:04 +0200 bundle2-push: introduce a list of part generating functions
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 15:26:04 +0200] rev 21904
bundle2-push: introduce a list of part generating functions Instead of explicitly calling a few function to generate part in the bundle, we now have a list of all part generators. This should make it easier for extensions to adds new part in the bundle. This new way to extend the push deprecates the old `_pushbundle2extraparts` way.
Wed, 02 Jul 2014 12:55:09 +0200 bundle2-push: move changegroup push validation inside _pushb2ctx
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 12:55:09 +0200] rev 21903
bundle2-push: move changegroup push validation inside _pushb2ctx When bundle2 push includes more than just changesets, we may have no changegroup to push yet still have other data to push. So we now try to performs a bundle2 push in all cases. The check for changegroup inclusion is moved into the ``_pushb2ctx`` function in charge of creating the changegroup part. The bundle2 part is aborted if no actual payload part have been added to the bundle2.
Mon, 07 Jul 2014 12:30:31 +0200 push: use `stepsdone` to control changegroup push through bundle10 or bundle20
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 07 Jul 2014 12:30:31 +0200] rev 21902
push: use `stepsdone` to control changegroup push through bundle10 or bundle20 We use the newly introduced `pushop.stepsdone` attribute to inform older methods than changegroup have already been pushed using a newer method.
Wed, 02 Jul 2014 12:48:54 +0200 push: add a ``pushop.stepsdone`` attribute
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 12:48:54 +0200] rev 21901
push: add a ``pushop.stepsdone`` attribute This attribute will record what steps were performed during the bundle2 push. This will control whenever the old way push must be performed or skipped. This will ultimately be used by changegroup, phases, obsmarkers, bookmarks and any other kind of data ones may want to exchange even when bundle2 support is missing.
Wed, 02 Jul 2014 16:17:54 +0200 bundle2: add a ``bundle20.nbparts`` property
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 16:17:54 +0200] rev 21900
bundle2: add a ``bundle20.nbparts`` property This property can be used to know how much parts have been added to the bundle2. This will be useful to check if any part have been generated for a push.
Wed, 02 Jul 2014 11:42:35 +0200 bundle2-push: extract changegroup logic in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 11:42:35 +0200] rev 21899
bundle2-push: extract changegroup logic in its own function We extract the creation of changegroup related parts into its own function. This precludes the inclusion of more diverse data during the bundle2 push. We use a closure to carry the logic that need to be perform when processing the server reply.
Wed, 02 Jul 2014 14:09:24 +0200 bundle2: call _pushbundle2extraparts a bit sooner
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Jul 2014 14:09:24 +0200] rev 21898
bundle2: call _pushbundle2extraparts a bit sooner This is the first step of a refactoring that will ease the inclusion of new part in the bundle2 push and includes more information (like phases) in this push We need to move the function a bit sooner to be able to group the generation of `b2x:check:heads` and `b2x:changegroup` part in an external function. We move it sooner to preserve parts creation order bundle2 tests rely on. At the ends of this refactoring the `_pushbundle2extraparts` will be replaced by another mechanism anyway.
Tue, 15 Jul 2014 23:34:13 +0900 templatekw: add 'subrepos' keyword to show updated subrepositories
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 15 Jul 2014 23:34:13 +0900] rev 21897
templatekw: add 'subrepos' keyword to show updated subrepositories 'subrepos' template keyword newly added by this patch shows updated subrepositories. For the compatibility with the list of subrepositories shown in the editor at commit: - 'subrepos' is empty, at revisions removing '.hgsub' itself - 'subrepos' is calculated between the revision and the first parent of it, at merge revisions To avoid silent regression, this patch also confirms "hg diff" of ".hgsubstate" and parents for each target revisions in the test.
Tue, 15 Jul 2014 23:34:13 +0900 templatekw: add 'currentbookmark' keyword to show current bookmark easily
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 15 Jul 2014 23:34:13 +0900] rev 21896
templatekw: add 'currentbookmark' keyword to show current bookmark easily Before this patch, complicated template expression below is required to show current active bookmark if it is associated with the changeset. "{bookmarks % '{ifeq(bookmark, current, \"{bookmark}\")}'}" This patch add 'currentbookmark' keyword to show current bookmark easily.
Wed, 16 Jul 2014 14:53:03 -0700 context: extend efficient manifest filtering to when all paths are files
Siddharth Agarwal <sid0@fb.com> [Wed, 16 Jul 2014 14:53:03 -0700] rev 21895
context: extend efficient manifest filtering to when all paths are files On a repository with over 250,000 files and 700,000 commits, this improves cases like hg status --rev <rev> -- <file> # rev is not . from 2.1 seconds to 1.4 seconds. There is further scope for improvement here: for a single file or a small set of files, it is probably more efficient to use filelog linkrevs when possible. However there will always be cases where that will fail (multiple commits pointing to the same file revision, removed files...), so this is independently useful.
Sat, 12 Jul 2014 00:37:08 -0700 revset: remove no longer used _missingancestors revset
Siddharth Agarwal <sid0@fb.com> [Sat, 12 Jul 2014 00:37:08 -0700] rev 21894
revset: remove no longer used _missingancestors revset This was undocumented.
Sat, 12 Jul 2014 00:31:36 -0700 revset: replace _missingancestors optimization with only revset
Siddharth Agarwal <sid0@fb.com> [Sat, 12 Jul 2014 00:31:36 -0700] rev 21893
revset: replace _missingancestors optimization with only revset (::a - ::b) is equivalent to only(a, b).
Sat, 28 Jun 2014 01:42:39 +0200 tags: introduce _readtaghist function
Angel Ezquerra <angel.ezquerra@gmail.com> [Sat, 28 Jun 2014 01:42:39 +0200] rev 21892
tags: introduce _readtaghist function The existing _readtags function has been modified a little and renamed _readtaghist. A new _readtaghist function has been added, which is a wrappger around _readtaghist. Its output is the same as the old _readtaghist. The purpose of this change is to make it possible to automatically merge tag files. In order to do so we will need to get the line numbers for each of the tag-node pairs on the first merge parent. This is not used yet, but will be used on a follow up patch that will introduce an automatic tag merge algorithm. I performed some tests to compare the effect of this change. I used timeit to run the test-tags.t test a 9 times with and without this patch. The results were: - without this patch: 3 loops, best of 3: 8.55 sec per loop - with this patch: 3 loops, best of 3: 8.49 sec per loop The the test was on average was slightly faster with this patch (although the difference was probably not statistically significant).
Fri, 20 Jun 2014 00:42:35 +0900 subrepo: ensure "close()" execution at the end of "_initrepo()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 Jun 2014 00:42:35 +0900] rev 21891
subrepo: ensure "close()" execution at the end of "_initrepo()" Before this patch, "close()" for the file object opened in "_initrepo()" may not be executed, if unexpected exception is raised, because it isn't executed in "finally" clause. This patch ensures "close()" execution at the end of "_initrepo()" by moving it into "finally" clause. This patch puts configuration lines into "lines" array and write them out at once, to narrow the scope of "try"/"finally" for review-ability. This patch doesn't use "vfs.write()", because: - current "vfs.write()" implementation doesn't take "mode" argument to open file in "text" mode - writing hgrc file out in binary mode may break backward compatibility
Fri, 20 Jun 2014 00:41:31 +0900 subrepo: add test whether "[paths]" is configured correctly at subrepo creation
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 Jun 2014 00:41:31 +0900] rev 21890
subrepo: add test whether "[paths]" is configured correctly at subrepo creation This test is added for changes in the subsequent patch. This test doesn't use "(glob)" for expected output, because "[paths]" is configured at subrepo creation by "_abssource()" using "posixpath.join()" to join path components.
Fri, 20 Jun 2014 00:21:19 +0900 subrepo: ensure "close()" execution at the end of "_cachestorehash()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 Jun 2014 00:21:19 +0900] rev 21889
subrepo: ensure "close()" execution at the end of "_cachestorehash()" Before this patch, "close()" for the file object opened in "_cachestorehash()" may not be executed, if unexpected exception is raised, because it isn't executed in "finally" clause. This patch ensures "close()" execution at the end of "_cachestorehash()" by moving it into "finally" clause.
Fri, 20 Jun 2014 00:21:19 +0900 subrepo: ensure "close()" execution at the end of "_readstorehashcache()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 Jun 2014 00:21:19 +0900] rev 21888
subrepo: ensure "close()" execution at the end of "_readstorehashcache()" Before this patch, "close()" for the file object opened in "_readstorehashcache()" may not be executed, if unexpected exception is raised, because it isn't executed in "finally" clause. This patch ensures "close()" execution at the end of "_readstorehashcache()" by moving it into "finally" clause.
Fri, 20 Jun 2014 00:21:19 +0900 subrepo: ensure "close()" execution at the end of "_calcfilehash()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 Jun 2014 00:21:19 +0900] rev 21887
subrepo: ensure "close()" execution at the end of "_calcfilehash()" Before this patch, "close()" for the file object opened in "_calcfilehash()" may not be executed, if unexpected exception is raised, because it isn't executed in "finally" clause. This patch ensures "close()" execution at the end of "_calcfilehash()" by moving it into "finally" clause.
Fri, 20 Jun 2014 00:21:19 +0900 subrepo: ensure "lock.release()" execution at the end of "_cachestorehash()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 20 Jun 2014 00:21:19 +0900] rev 21886
subrepo: ensure "lock.release()" execution at the end of "_cachestorehash()" Before this patch, "lock.release()" for "self._repo" in "_cachestorehash()" of "hgsubrepo" may not be executed, if unexpected exception is raised, because it isn't executed in "finally" clause. This patch ensures "lock.release()" execution at the end of "_cachestorehash()" by moving it into "finally" clause.
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 +30000 tip