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.
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".
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.
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.
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.
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.
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.
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.
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.
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$
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
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().
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.
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.
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().
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.