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.

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.

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.

revlog: clarify flagprocessor documentation The words "text", "newtext", "bool" could be confusing. Use explicit "text" or "rawtext" and document more about the "bool".

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.

hook: add hook name information to external hook While we are here, we can also add the hook name information to external hook.

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.

hook: use 'htype' in 'hook' Same rational as for 'runhooks', we fix the naming in another function.

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.

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.

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.

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$

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

largefiles: remove unused readstandin() Now, there is no client of readstandin().

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.

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.