Thu, 30 Mar 2017 17:58:03 -0700 revlog: use raw content when building delta
Jun Wu <quark@fb.com> [Thu, 30 Mar 2017 17:58:03 -0700] rev 31752
revlog: use raw content when building delta Using external content provided by flagprocessor when building revlog delta is wrong, because deltas are applied to raw contents in revlog. This patch fixes the above issue by adding "raw=True". test-revlog-raw.py now shows "local test passed", but there is more to fix.
Thu, 30 Mar 2017 15:34:08 -0700 revlog: fix _cache usage in revision()
Jun Wu <quark@fb.com> [Thu, 30 Mar 2017 15:34:08 -0700] rev 31751
revlog: fix _cache usage in revision() As documented at revlog.__init__, revlog._cache stores raw text. The current read and write usage of "_cache" in revlog.revision lacks of raw=True check. This patch fixes that by adding check about raw, and storing rawtext explicitly in _cache. Note: it may slow down cache hit code path when raw=False and flags=0. That performance issue will be fixed in a later patch. test-revlog-raw now points us to a new problem.
Thu, 30 Mar 2017 14:56:09 -0700 revlog: rename some "text"s to "rawtext"
Jun Wu <quark@fb.com> [Thu, 30 Mar 2017 14:56:09 -0700] rev 31750
revlog: rename some "text"s to "rawtext" This makes code easier to understand. "_addrevision" is left untouched - it will be changed in a later patch.
Thu, 30 Mar 2017 07:59:48 -0700 revlog: clarify flagprocessor documentation
Jun Wu <quark@fb.com> [Thu, 30 Mar 2017 07:59:48 -0700] rev 31749
revlog: clarify flagprocessor documentation The words "text", "newtext", "bool" could be confusing. Use explicit "text" or "rawtext" and document more about the "bool".
Thu, 30 Mar 2017 20:48:57 -0700 revlog: add a stronger test for raw processing
Jun Wu <quark@fb.com> [Thu, 30 Mar 2017 20:48:57 -0700] rev 31748
revlog: add a stronger test for raw processing There are some issues about revlog raw processing (flag processor). The test is relatively strong covering many cases. It will verify fixes.
Fri, 31 Mar 2017 11:53:56 +0200 hook: add hook name information to external hook
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 11:53:56 +0200] rev 31747
hook: add hook name information to external hook While we are here, we can also add the hook name information to external hook.
Fri, 31 Mar 2017 11:08:11 +0200 hook: provide hook type information to external hook
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 11:08:11 +0200] rev 31746
hook: provide hook type information to external hook The python hooks have access to the hook type information. There is not reason for external hook to not be aware of it too. For the record my use case is to make sure a hook script is configured for the right type.
Fri, 31 Mar 2017 11:06:42 +0200 hook: use 'htype' in 'hook'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 11:06:42 +0200] rev 31745
hook: use 'htype' in 'hook' Same rational as for 'runhooks', we fix the naming in another function.
Fri, 31 Mar 2017 11:03:23 +0200 hook: use 'htype' in 'runhooks'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 11:03:23 +0200] rev 31744
hook: use 'htype' in 'runhooks' Same rational as for '_pythonhook', 'htype' is more accurate and less error prone. We just fixed an error from the 'name'/'hname' confusion and this should prevent them in the future.
Fri, 31 Mar 2017 11:02:05 +0200 hook: fix name used in untrusted message
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 11:02:05 +0200] rev 31743
hook: fix name used in untrusted message The name used in the message we issue when a hook is untrusted was using "name" which is actually the hook type and not the name of the hook.
Fri, 31 Mar 2017 10:59:37 +0200 hook: use "htype" as variable name in _pythonhook
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 10:59:37 +0200] rev 31742
hook: use "htype" as variable name in _pythonhook We rename 'name' to 'htype' because it fits the variable content better. Multiple python hooks already use 'htype' as a name for the argument. This makes the difference with "hname" clearer and the code less error prone.
Thu, 30 Mar 2017 17:29:03 +0200 run-tests: auto-replace 'TXNID' output
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 30 Mar 2017 17:29:03 +0200] rev 31741
run-tests: auto-replace 'TXNID' output Hooks related to the transaction are aware of the transaction id. By definition this txn-id is unique and different for each transaction. As a result it can never be predicted in test and always needs matching. As a result, touching any like with this data is annoying. We solve the problem once and for all by installing an automatic replacement. In test, this will now show as: TXNID=TXN:$ID$
Sat, 01 Apr 2017 02:32:49 +0900 largefiles: use readasstandin() to read hex hash directly from filectx
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:49 +0900] rev 31740
largefiles: use readasstandin() to read hex hash directly from filectx BTW, C implementation of hexdigest() for SHA-1/256/512 returns hex hash in lower case, and doctest in Python standard hashlib assumes that, too. But it isn't explicitly described in API document or so. Therefore, we can't assume that hexdigest() always returns hex hash in lower case, for any hash algorithms, on any Python runtimes and versions. From point of view of that, it is reasonable for portability that 40800668e019 applies lower() on hex hash in overridefilemerge(). But on the other hand, in largefiles extension, there are still many code paths comparing between hex hashes or storing hex hash into standin file, without lower(). Switching to hash algorithm other than SHA-1 may be good chance to clarify our policy about hexdigest()-ed hash value string. - assume that hexdigest() always returns hex hash in lower case, or - apply lower() on hex hash in appropriate layers to ensure lower-case-ness of it for portability
Sat, 01 Apr 2017 02:32:49 +0900 largefiles: remove unused readstandin()
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:49 +0900] rev 31739
largefiles: remove unused readstandin() Now, there is no client of readstandin().
Sat, 01 Apr 2017 02:32:48 +0900 largefiles: make copytostore() accept only changectx as the 2nd argument (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:48 +0900] rev 31738
largefiles: make copytostore() accept only changectx as the 2nd argument (API) As the name describes, the 2nd argument 'revorctx' of copytostore() can accept non-changectx value, for historical reason, But, since 10561eb97c7f, copyalltostore(), the only one copytostore() client in Mercurial source tree, always passes changectx as 'revorctx'. Therefore, it is reasonable to make copytostore() accept only changectx as the 2nd argument, now.
Sat, 01 Apr 2017 02:32:48 +0900 largefiles: remove unused keyword argument of copytostore() (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:48 +0900] rev 31737
largefiles: remove unused keyword argument of copytostore() (API) AFAIK, 'uploaded' argument of copytostore() (or copytocache(), before renaming at c65f5b6e26d4) has been never used both on caller and callee sides, since official release of bundled largefiles extension.
Sat, 01 Apr 2017 02:32:48 +0900 largefiles: add copytostore() fstandin argument to replace readstandin() (API)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:48 +0900] rev 31736
largefiles: add copytostore() fstandin argument to replace readstandin() (API) copyalltostore(), only one caller of copytostore(), already knows standin file name of the target largefile. Therefore, passing it to copytostore() is more efficient than calculating it in copytostore() or readstandin().
Sat, 01 Apr 2017 02:32:47 +0900 largefiles: replace readstandin() by readasstandin()
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:47 +0900] rev 31735
largefiles: replace readstandin() by readasstandin() These code paths already (or should, for efficiency at repetition) know the target changectx and path of standin file.
Sat, 01 Apr 2017 02:32:31 +0900 largefiles: introduce readasstandin() to read hex hash from given filectx
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 01 Apr 2017 02:32:31 +0900] rev 31734
largefiles: introduce readasstandin() to read hex hash from given filectx This will be used to centralize and encapsulate the logic to read hash from given (filectx of) standin file. readstandin() isn't suitable for this purpose, because there are some code paths, which want to read hex hash directly from filectx.
Thu, 30 Mar 2017 03:50:10 -0700 rebase: abort hg pull --rebase if rebase.requiredest is set (issue5514)
Ryan McElroy <rmcelroy@fb.com> [Thu, 30 Mar 2017 03:50:10 -0700] rev 31733
rebase: abort hg pull --rebase if rebase.requiredest is set (issue5514) Previously, the pull would succeed, but the subsequent rebase would fail due to the rebase.requiredest flag. Now abort earlier with a more useful error message.
Thu, 30 Mar 2017 03:50:10 -0700 rebase: demonstrate behavior with requiredest and pull --rebase
Ryan McElroy <rmcelroy@fb.com> [Thu, 30 Mar 2017 03:50:10 -0700] rev 31732
rebase: demonstrate behavior with requiredest and pull --rebase
Thu, 30 Mar 2017 03:50:10 -0700 rebase: allow destination-free continue and abort (issue5513)
Ryan McElroy <rmcelroy@fb.com> [Thu, 30 Mar 2017 03:50:10 -0700] rev 31731
rebase: allow destination-free continue and abort (issue5513)
Thu, 30 Mar 2017 03:50:10 -0700 rebase: test to show brokenness with requiredest
Ryan McElroy <rmcelroy@fb.com> [Thu, 30 Mar 2017 03:50:10 -0700] rev 31730
rebase: test to show brokenness with requiredest As shown in issue5513, --continue is broken when destination is required. This adds a patch that demonstates this silly behavior, which will be fixed in a future patch.
Thu, 30 Mar 2017 03:50:10 -0700 rebase: move destination test to new test file
Ryan McElroy <rmcelroy@fb.com> [Thu, 30 Mar 2017 03:50:10 -0700] rev 31729
rebase: move destination test to new test file We'll be adding a lot more tests here, so it makes sense to have this in its own file now.
Sat, 01 Apr 2017 00:21:17 -0400 templatefilter: add support for 'long' to json()
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Apr 2017 00:21:17 -0400] rev 31728
templatefilter: add support for 'long' to json() When disabling the '#requires serve' check in test-hgwebdir.t and running it on Windows, several 500 errors popped up when querying '?style=json', with the following in the error log: File "...\\mercurial\\templater.py", line 393, in runfilter "keyword '%s'") % (filt.func_name, dt)) Abort: template filter 'json' is not compatible with keyword 'lastchange' The swallowed exception at that point was: File "...\\mercurial\\templatefilters.py", line 242, in json raise TypeError('cannot encode type %s' % obj.__class__.__name__) TypeError: cannot encode type long This corresponds to 'lastchange' being populated by hgweb.common.get_stat(), which uses os.stat().st_mtime. os.stat_float_times() is being disabled in util, so the type for the times is 'long' on Windows, and 'int' on Linux.
Thu, 30 Mar 2017 21:40:10 +0200 hgweb: prefix line id by ctx shortnode in filelog when patches are shown
Denis Laxalde <denis@laxalde.org> [Thu, 30 Mar 2017 21:40:10 +0200] rev 31727
hgweb: prefix line id by ctx shortnode in filelog when patches are shown When "patch" query parameter is present in requests to filelog view, line ids in patches diff are no longer unique in the page since several patches are shown on the same page. We now prefix line id by changeset shortnode when several patches are displayed in the same page to have unique line ids overall.
Wed, 29 Mar 2017 12:14:20 -0700 test-check-code: prevent files being added to the root directory
Jun Wu <quark@fb.com> [Wed, 29 Mar 2017 12:14:20 -0700] rev 31726
test-check-code: prevent files being added to the root directory Adding new files in the root directory is probably a mistake, and is usually discouraged [1]. The test catches it to avoid mistakes like [2]. Modify the test if files need to be added in the root. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-July/086442.html [2]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095836.html
Wed, 29 Mar 2017 09:54:34 -0400 sslutil: clarify internal documentation
Matt Harbison <matt_harbison@yahoo.com> [Wed, 29 Mar 2017 09:54:34 -0400] rev 31725
sslutil: clarify internal documentation I ran into this python issue with an incomplete certificate chain on Windows recently, and this is the clarification that came from that experimenting. The comment I left on the bug tracker [1] with a reference to the CPython code [2] indicates that the original problem I had is a different bug, but happened to be mentioned under issue20916 on the Python bug tracker. [1] https://bz.mercurial-scm.org/show_bug.cgi?id=5313#c7 [2] https://hg.python.org/cpython/file/v2.7.12/Modules/_ssl.c#l628
Wed, 29 Mar 2017 16:28:51 -0700 unionrepo: avoid unnecessary node -> rev conversion
Jun Wu <quark@fb.com> [Wed, 29 Mar 2017 16:28:51 -0700] rev 31724
unionrepo: avoid unnecessary node -> rev conversion
Wed, 29 Mar 2017 16:28:00 -0700 bundlerepo: avoid unnecessary node -> rev conversion
Jun Wu <quark@fb.com> [Wed, 29 Mar 2017 16:28:00 -0700] rev 31723
bundlerepo: avoid unnecessary node -> rev conversion
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip