node: stop converting binascii.Error to TypeError in bin()
Changeset
f574cc00831a introduced the wrapper, to make bin() behave like on
Python 2, where it raised TypeError in many cases. Another previous approach,
changing callers to catch binascii.Error in addition to TypeError, was backed
out after negative review feedback [1].
However, I think it’s worth reconsidering the approach. Now that we’re on
Python 3 only, callers have to catch only binascii.Error instead of both.
Catching binascii.Error instead of TypeError has the advantage that it’s less
likely to cover a programming error (e.g. passing an int to bin() raises
TypeError). Also, raising TypeError never made sense semantically when bin()
got an argument of valid type.
As a side-effect, this fixed an exception in test-http-bad-server.t. The TODO
was outdated: it was not an uncaught ValueError in batch.results() but uncaught
TypeError from the now removed wrapper. Now that bin() raises binascii.Error
instead of TypeError, it gets converted to a proper error in
wirepeer.heads.<locals>.decode() that catches ValueError (superclass of
binascii.Error). This is a good example of why this changeset is a good idea.
Catching TypeError instead of ValueError there would not make much sense.
[1] https://phab.mercurial-scm.org/D2244
Octopus Merge Support
=====================
This will be moderately complicated, as we'll need to synthesize phony
changeset entries to explode the octopus into "revisions" that only
have two parents each. For today, we can probably just do something like
aaaaaaaaaaaaaaaaaaXX{20 bytes of exploded node's hex sha}
where XX is a counter (so we could have as many as 255 parents in a
git commit - more than I think we'd ever see.) That means that we can
install some check in this extension to disallow checking out or
otherwise interacting with the `aaaaaaaaaaaaaaaaaa` revisions.
Interface Creation
====================
We at least need an interface definition for `changelog` in core that
this extension can satisfy, and again for `basicstore`.
Reason About Locking
====================
We should spend some time thinking hard about locking, especially on
.git/index etc. We're probably adequately locking the _git_
repository, but may not have enough locking correctness in places
where hg does locking that git isn't aware of (notably the working
copy, which I believe Git does not lock.)