Wed, 01 Oct 2014 12:35:18 -0500 merge with i18n stable 3.1.2
Matt Mackall <mpm@selenic.com> [Wed, 01 Oct 2014 12:35:18 -0500] rev 22603
merge with i18n
Tue, 30 Sep 2014 16:59:07 -0400 diff: document the nobinary option stable
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 30 Sep 2014 16:59:07 -0400] rev 22602
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.
Tue, 30 Sep 2014 13:43:30 -0300 i18n-pt_BR: minor fixes and rewording on histedit help text stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 30 Sep 2014 13:43:30 -0300] rev 22601
i18n-pt_BR: minor fixes and rewording on histedit help text
Tue, 30 Sep 2014 10:17:59 -0300 i18n-pt_BR: synchronized with c712238c4f9b stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 30 Sep 2014 10:17:59 -0300] rev 22600
i18n-pt_BR: synchronized with c712238c4f9b
Tue, 30 Sep 2014 10:13:25 -0300 merge with i18n stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 30 Sep 2014 10:13:25 -0300] rev 22599
merge with i18n
Mon, 22 Sep 2014 15:39:21 -0300 i18n-pt_BR: synchronized with 802dffd62de5 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Mon, 22 Sep 2014 15:39:21 -0300] rev 22598
i18n-pt_BR: synchronized with 802dffd62de5
Sun, 14 Sep 2014 20:32:34 -0400 filelog: censored files compare against empty data, have 0 size
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.
Wed, 03 Sep 2014 22:14:20 -0400 filelog: raise CensoredNodeError when hash checks fail with censor metadata
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.
Wed, 03 Sep 2014 15:59:03 -0400 error: add CensoredNodeError, will be thrown when content deliberately erased
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".
Tue, 30 Sep 2014 16:01:19 -0700 files: cache repo.dirstate
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip