Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 30 Sep 2014 10:13:25 -0300] rev 22599
merge with i18n
Wagner Bruna <wbruna@softwareexpress.com.br> [Mon, 22 Sep 2014 15:39:21 -0300] rev 22598
i18n-pt_BR: synchronized with
802dffd62de5
Mike Edgar <adgar@google.com> [Sun, 14 Sep 2014 20:32:34 -0400] rev 22597
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.
Mike Edgar <adgar@google.com> [Wed, 03 Sep 2014 22:14:20 -0400] rev 22596
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.
Mike Edgar <adgar@google.com> [Wed, 03 Sep 2014 15:59:03 -0400] rev 22595
error: add CensoredNodeError, will be thrown when content deliberately erased
This change introduces the error plus a corresponding catch in dispatch, to
provide localized error messages.
The verb "censor" is used in this commit and all following to refer to erasing
the content of a revlog revision (filelog, for now) without recalculating node
IDs, leaving that revision invalid. Further work must be done to safely share
such revision data with compliant clients.
I find the analogy to censorship straightforward; for less politically
charged options, consider "erase", "excise", "expunge", or "blackhole".
Siddharth Agarwal <sid0@fb.com> [Tue, 30 Sep 2014 16:01:19 -0700] rev 22594
files: cache repo.dirstate
For a large repo, 'hg files' goes from 2.27 seconds to 1.92.
Siddharth Agarwal <sid0@fb.com> [Tue, 30 Sep 2014 15:21:35 -0700] rev 22593
files: only check for removed, not unknown or missing
ctx.matches() doesn't return unknown files, and repo.dirstate[f] never returns
'!' for an answer.
Siddharth Agarwal <sid0@fb.com> [Tue, 30 Sep 2014 14:39:58 -0700] rev 22592
files: use ctx.matches instead of ctx.walk
ctx.matches() is an optimized form of ctx.walk() when we don't care about the
state of files on disk.
For a large repo, 'hg files > /dev/null' drops from 3.7 seconds to 2.3.
Siddharth Agarwal <sid0@fb.com> [Tue, 30 Sep 2014 15:45:48 -0700] rev 22591
files: actually filter out removed files
'hg files' makes an attempt to filter out removed files, but that doesn't work
because repo.dirstate[f] returns lowercase 'r', not uppercase.
Mads Kiilerich <madski@unity3d.com> [Wed, 01 Oct 2014 01:08:17 +0200] rev 22590
subrepo: remove superfluous newline from subrepo prompt