Tue, 01 Oct 2013 00:35:07 +0900 rebase: catch RepoLookupError at restoring rebase state for abort/continue stable
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".
Tue, 01 Oct 2013 00:35:07 +0900 histedit: suggest "histedit --abort" for inconsistent histedit state stable
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".
Mon, 30 Sep 2013 14:23:14 +0200 repoview: have unfilteredpropertycache using the underlying cache stable
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.
Mon, 30 Sep 2013 14:36:11 +0200 repoview: make propertycache.setcache compatible with repoview stable
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.
Tue, 01 Oct 2013 16:41:04 -0300 i18n-pt_BR: synchronized with 1aaefba2a3a9 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Tue, 01 Oct 2013 16:41:04 -0300] rev 19844
i18n-pt_BR: synchronized with 1aaefba2a3a9
Tue, 01 Oct 2013 10:44:59 -0700 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 01 Oct 2013 10:44:59 -0700] rev 19843
merge with stable
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip