Tue, 01 Oct 2013 12:20:31 +0200 shelve: new output format for shelve listings
David Soria Parra <dsp@experimentalworks.net> [Tue, 01 Oct 2013 12:20:31 +0200] rev 19855
shelve: new output format for shelve listings Use a more condensed and mercurial-like output format for shelve listing. We don't prefix the message with 'shelved from...' anymore as our default name contains the branch name or the user used his own name. To avoid just printing the last commit message, we drop writing the description to stdout. old output: default [1s ago] shelved from default (01ba9745): create conflict new output: default (1s ago) create conflict
Thu, 29 Aug 2013 09:22:13 -0700 shelve: add a shelve extension to save/restore working changes
David Soria Parra <dsp@experimentalworks.net> [Thu, 29 Aug 2013 09:22:13 -0700] rev 19854
shelve: add a shelve extension to save/restore working changes This extension saves shelved changes using a temporary draft commit, and bundles the temporary commit and its draft ancestors, then strips them. This strategy makes it possible to use Mercurial's bundle and merge machinery to resolve conflicts if necessary when unshelving, even when the destination commit or its ancestors have been amended, squashed, or evolved. (Once a change has been unshelved, its associated unbundled commits are either rolled back or stripped.) Storing the shelved change as a bundle also avoids the difficulty that hidden commits would cause, of making it impossible to amend the parent if it is a draft commits (a common scenario). Although this extension shares its name and some functionality with the third party hgshelve extension, it has little else in common. Notably, the hgshelve extension shelves changes as unified diffs, which makes conflict resolution a matter of finding .rej files and conflict markers, and cleaning up the mess by hand. We do not yet allow hunk-level choosing of changes to record. Compared to the hgshelve extension, this is a small regression in usability, but we hope to integrate that at a later point, once the record machinery becomes more reusable and robust.
Tue, 01 Oct 2013 12:20:29 +0200 localrepo: make report level in repo.transaction configurable
David Soria Parra <dsp@experimentalworks.net> [Tue, 01 Oct 2013 12:20:29 +0200] rev 19853
localrepo: make report level in repo.transaction configurable repo.transaction always writes to stderr when a transaction aborts. In order to be able to abort a transaction quietly (e.g shelve needs a temporary view on the repo) we need to make the report level configurable.
Tue, 01 Oct 2013 17:00:03 -0700 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 01 Oct 2013 17:00:03 -0700] rev 19852
merge with stable
Tue, 01 Oct 2013 16:55:20 -0700 Added signature for changeset e7fa36d2ad3a stable
Matt Mackall <mpm@selenic.com> [Tue, 01 Oct 2013 16:55:20 -0700] rev 19851
Added signature for changeset e7fa36d2ad3a
Tue, 01 Oct 2013 16:55:14 -0700 Added tag 2.7.2 for changeset e7fa36d2ad3a stable
Matt Mackall <mpm@selenic.com> [Tue, 01 Oct 2013 16:55:14 -0700] rev 19850
Added tag 2.7.2 for changeset e7fa36d2ad3a
Tue, 01 Oct 2013 00:35:07 +0900 rebase: catch RepoLookupError at restoring rebase state for summary stable 2.7.2
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 01 Oct 2013 00:35:07 +0900] rev 19849
rebase: catch RepoLookupError at restoring rebase state for summary Before this patch, "hg summary" may fail, when there is inconsistent rebase state: 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 summary hook, and treat such state as "broken".
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip