FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:35:07 +0900] rev 19848
rebase: catch RepoLookupError at restoring rebase state for abort/continue
Before this patch, "rebase --abort"/"--continue" may fail, when rebase
state is inconsistent: for example, the root of rebase destination
revisions recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
abort/continue, and treat such state as "broken".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:35:07 +0900] rev 19847
histedit: suggest "histedit --abort" for inconsistent histedit state
Mercurial earlier than 2.7 allows users to do anything other than
starting new histedit, even though current histedit is not finished or
aborted yet. So, unfinished (and maybe inconsistent now) histedit
states may be left and forgotten in repositories.
Before this patch, histedit extension shows the message below, when it
detects such inconsistent state:
abort: REV is not an ancestor of working directory
(update to REV or descendant and run "hg histedit --continue" again)
But this message is incorrect, unless old Mercurial is re-installed,
because Mercurial 2.7 or later disallows users to update the working
directory to another revision.
This patch changes the hint message to suggest "hg histedit --abort".
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 14:23:14 +0200] rev 19846
repoview: have unfilteredpropertycache using the underlying cache
A `unfilteredpropertycache` is a kind of `propertycache` used on `localrepo` to
unsure it will always be run against unfiltered repo and stored only once.
As the cached value is never stored in the repoview instance, the descriptor
will always be called. Before this patch such calls always result in a call to
the `__get__` method of the `propertycache` on the unfiltered repo. That was
recomputing a new value on every access through a repoview.
We can't prevent the repoview's `unfilteredpropertycache` to get called on every
access. In that case the new code makes a standard attribute access to the
property. If a value is cached it will be used.
The `propertycache` test file have been augmented with test about this issue.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 30 Sep 2013 14:36:11 +0200] rev 19845
repoview: make propertycache.setcache compatible with repoview
Propertycache used standard attribute assignment. In the repoview case, this
assignment was forwarded to the unfiltered repo. This result in:
(1) unfiltered repo got a potentially wrong cache value,
(2) repoview never reused the cached value.
This patch replaces the standard attribute assignment by an assignment to
`objc.__dict__` which will bypass the `repoview.__setattr__`. This will not
affects other `propertycache` users and it is actually closer to the semantic we
need.
The interaction of `propertycache` and `repoview` are now tested in a python
test file.
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 01 Oct 2013 16:41:04 -0300] rev 19844
i18n-pt_BR: synchronized with
1aaefba2a3a9
Matt Mackall <mpm@selenic.com> [Tue, 01 Oct 2013 10:44:59 -0700] rev 19843
merge with stable