Added tag 3.1.2 for changeset
f768c888aaa6
parsers: fix Py2.4 argument parsing issue
Since
fa53d66b45a8, we were getting this strange message with Py2.4:
TypeError: argument 1 must be impossible<bad format char>, not int
..because we were using the 'n' type specifier introduced in 2.5.
It turns out that offset is actually a revision number index, which
ought to be an int anyway. So we store it in an int, use the 'i'
specifier, rely on Py_ParseTuple for range checking, and rename it to
avoid type confusion.
diff: document the nobinary option
Since
3fbef7ac26f0, we have a diff.nobinary option. This is handy, but
the only way I found out about it was by looking at the release notes
for 3.1, which is not something I normally do.
i18n-pt_BR: synchronized with
c712238c4f9b
i18n-pt_BR: synchronized with
802dffd62de5
filelog: censored files compare against empty data, have 0 size
To support "status" operations against working directories that are
the children of censored revisions, filelog must define "cmp" and "size"
for censored content.
filelog: raise CensoredNodeError when hash checks fail with censor metadata
With this change, when a revlog revision hash does not match its content, and
the content is empty with a special metadata key, the integrity failure is
assumed to be intentionally caused to remove sensitive content from repository
history.
To allow different Mercurial functionality to handle this scenario differently
a more specific exception is raised than "ordinary" hash failures.
Alternatives to this approach include, but are not limited to:
- Calling a hook when hashes mismatch to allow arbitrary tombstone validation.
Cons: Irresponsibly easy to disable integrity checking altogether.
- Returning empty revision data eagerly instead of raising, masking the error.
Cons: Push/pull won't roundtrip the tombstone, so client repos are unusable.
- Doing nothing differently at this layer. Callers must do their own detection
of tombstoned data if they want to handle some hash checks and not others.
- Impacts dozens of callsites, many of which don't have the revision data
- Would probably be missing one or two callsites at any given time
- Currently we throw a RevlogError, as do 12 other places in revlog.py.
Callers would need to parse the exception message and/or ensure
RevlogError is not thrown from any other part of their call tree.