Fri, 13 Jul 2012 21:52:28 +0200 peer: introduce canpush and improve error message
Sune Foldager <cryo@cyanite.org> [Fri, 13 Jul 2012 21:52:28 +0200] rev 17193
peer: introduce canpush and improve error message
Fri, 13 Jul 2012 21:47:06 +0200 peer: introduce real peer classes
Peter Arrenbrecht <peter.arrenbrecht@gmail.com> [Fri, 13 Jul 2012 21:47:06 +0200] rev 17192
peer: introduce real peer classes This change separates peer implementations from the repository implementation. localpeer currently is a simple pass-through to localrepository, except for legacy calls, which have already been removed from localpeer. This ensures that the local client code only uses the most modern peer API when talking to local repos. Peers have a .local() method which returns either None or the underlying localrepository (or descendant thereof). Repos have a .peer() method to return a freshly constructed localpeer. The latter is used by hg.peer(), and also to allow folks to pass either a peer or a repo to some generic helper methods. We might want to get rid of .peer() eventually. The only user of locallegacypeer is debugdiscovery, which uses it to pose as a pre-setdiscovery client. But we decided to leave the old API defined in locallegacypeer for clarity and maybe for other uses in the future. It might be nice to actually define the peer API directly in peer.py as stub methods. One problem there is, however, that localpeer implements lock/addchangegroup, whereas the true remote peers implement unbundle. It might be desireable to get rid of this distinction eventually.
Fri, 13 Jul 2012 21:46:53 +0200 peer: introduce peer methods to prepare for peer classes
Sune Foldager <cryo@cyanite.org> [Fri, 13 Jul 2012 21:46:53 +0200] rev 17191
peer: introduce peer methods to prepare for peer classes This introduces a peer method into all repository classes, which currently simply returns self. It also changes hg.repository so it now raises an exception if the supplied paths does not resolve to a localrepo or descendant. Finally, all call sites are changed to use the peer and local methods as appropriate, where peer is used whenever the code is dealing with a remote repository (even if it's on local disk).
Fri, 06 Jul 2012 14:12:42 -0500 bookmarks: document behavior of -B/--bookmark in help
Augie Fackler <raf@durin42.com> [Fri, 06 Jul 2012 14:12:42 -0500] rev 17190
bookmarks: document behavior of -B/--bookmark in help
Fri, 06 Jul 2012 14:11:58 -0500 test-bookmarks-pushpull.t: verify correct push -B behavior
Augie Fackler <raf@durin42.com> [Fri, 06 Jul 2012 14:11:58 -0500] rev 17189
test-bookmarks-pushpull.t: verify correct push -B behavior I wasn't able to find a test that proved this behavior worked, so I felt obligated to write a quick test so it won't regress in the future.
Wed, 11 Jul 2012 11:52:42 +0200 debugrevlog: handle numrevs == numfull case (issue3537)
Patrick Mezard <patrick@mezard.eu> [Wed, 11 Jul 2012 11:52:42 +0200] rev 17188
debugrevlog: handle numrevs == numfull case (issue3537) Instead of tracing back with a ZeroDivisionError.
Tue, 10 Jul 2012 09:11:53 -0700 templatekw/help: document the {parents} keyword
epriestley <hg@yghe.net> [Tue, 10 Jul 2012 09:11:53 -0700] rev 17187
templatekw/help: document the {parents} keyword The {parents} keyword does not appear in the generated documentation for templates because it is added by `changeset_templater` (and this is because its behavior depends on `ui`, so it can't be defined as a normal template keyword; see comments in `changeset_templater._show()`). Add it to the documentation synthetically by creating a stub documentation function. Test plan: built the docs and examined the man page to verify that this keyword is now documented. I'm not sure how to test the i18n extraction part, but assume it will just work given that this patch doesn't do anything too crazy.
Sat, 07 Jul 2012 00:47:55 -0400 revset: add destination() predicate
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Jul 2012 00:47:55 -0400] rev 17186
revset: add destination() predicate This predicate is used to find csets that were created because of a graft, transplant or rebase --keep. An optional revset can be supplied, in which case the result will be limited to those copies which specified one of the revs as the source for the command. hg log -r destination() # csets copied from anywhere hg log -r destination(branch(default)) # all csets copied from default hg log -r origin(x) or destination(origin(x)) # all instances of x This predicate will follow a cset through different types of copies. Given a repo with a cset 'S' that is grafted to create G(S), which itself is transplanted to become T(G(S)): o-S / o-o-G(S) \ o-T(G(S)) hg log -r destination( S ) # { G(S), T(G(S)) } hg log -r destination( G(S) ) # { T(G(S)) } The implementation differences between the three different copy commands (see the origin() predicate) are not intentionally exposed, however if the transplant was a graft instead: hg log -r destination( G(S) ) # {} because the 'extra' field in G(G(S)) is S, not G(S). The implementation cannot correct this by following sources before G(S) and then select the csets that reference those sources because the cset provided to the predicate would also end up selected. If there were more than two copies, sources of the argument would also get selected. Note that the convert extension does not currently update the 'extra' map in its destination csets, and therefore copies made prior to the convert will be missing from the resulting set. Instead of the loop over 'subset', the following almost works, but does not select a transplant of a transplant. That is, 'destination(S)' will only select T(S). dests = set([r for r in subset if _getrevsource(repo, r) in args])
Sat, 07 Jul 2012 00:47:30 -0400 revset: add origin() predicate
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Jul 2012 00:47:30 -0400] rev 17185
revset: add origin() predicate This predicate is used to find the original source of csets created by a graft, transplant or rebase --keep. If a copied cset is itself copied, only the source of the original copy is selected. hg log -r origin() # all src csets, anywhere hg log -r origin(branch(default)) # all srcs of copies on default By following through different types of copy commands and only selecting the original cset, the implementation differences between the copy commands are hidden. (A graft of a graft preserves the original source in its 'extra' map, while transplant and rebase use the immediate source specified for the command). Given a repo with a cset S that is grafted to create G(S), which itself is grafted to become G(G(S)) o-S / o-o-G(S) \ o-G(G(S)) hg log -r origin( G(S) ) # { S } hg log -r origin( G(G(S)) ) # { S }, NOT { G(S) } Even if the last graft were a transplant hg log -r origin( T(G(S)) ) # { S } A rebase without --keep essentially strips the source, so providing the cset that results to this predicate will yield an empty set. Note that the convert extension does not currently update the 'extra' map in its destination csets, and therefore copies made prior to the convert will be unable to find their source.
Mon, 16 Jul 2012 15:50:19 +0200 convert: remove unused newnames variable in filemap
Patrick Mezard <patrick@mezard.eu> [Mon, 16 Jul 2012 15:50:19 +0200] rev 17184
convert: remove unused newnames variable in filemap
Thu, 12 Jul 2012 03:03:19 +0200 push: fix bug in detection of remote obsolete support
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 12 Jul 2012 03:03:19 +0200] rev 17183
push: fix bug in detection of remote obsolete support Current code check obsolete availability in local repo.
Wed, 11 Jul 2012 18:22:07 +0200 incoming/outgoing: handle --graph in core
Patrick Mezard <patrick@mezard.eu> [Wed, 11 Jul 2012 18:22:07 +0200] rev 17182
incoming/outgoing: handle --graph in core
Sat, 14 Jul 2012 19:09:22 +0200 log: support --graph without graphlog extension
Patrick Mezard <patrick@mezard.eu> [Sat, 14 Jul 2012 19:09:22 +0200] rev 17181
log: support --graph without graphlog extension The glog command is preserved in the extension for backward compatibility.
Sat, 14 Jul 2012 18:55:21 +0200 graphlog: extract revset/support functions into cmdutil
Patrick Mezard <patrick@mezard.eu> [Sat, 14 Jul 2012 18:55:21 +0200] rev 17180
graphlog: extract revset/support functions into cmdutil
Wed, 11 Jul 2012 17:13:39 +0200 graphlog: extract ascii drawing code into graphmod
Patrick Mezard <patrick@mezard.eu> [Wed, 11 Jul 2012 17:13:39 +0200] rev 17179
graphlog: extract ascii drawing code into graphmod
Sun, 24 Jun 2012 18:11:52 +0200 patchbomb: rewrite getoutgoing() with revsets
Patrick Mezard <patrick@mezard.eu> [Sun, 24 Jun 2012 18:11:52 +0200] rev 17178
patchbomb: rewrite getoutgoing() with revsets Another version could have returned a revset expression from getoutgoing(), but we do not know how many times it will be resolved, so better do it once explicitely.
Sun, 24 Jun 2012 17:39:27 +0200 patchbomb: support --outgoing and revsets
Patrick Mezard <patrick@mezard.eu> [Sun, 24 Jun 2012 17:39:27 +0200] rev 17177
patchbomb: support --outgoing and revsets With --outgoing, input revisions were passed to getoutgoing() before being resolved.
Sat, 14 Jul 2012 19:21:31 +0200 patchbomb: make --outgoing ignore secret changesets
Patrick Mezard <patrick@mezard.eu> [Sat, 14 Jul 2012 19:21:31 +0200] rev 17176
patchbomb: make --outgoing ignore secret changesets getoutgoing() is just rewritten almost like revset.outgoing(), a follow-up will make it use revsets after the tests are adjusted.
Sun, 15 Jul 2012 14:48:50 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Sun, 15 Jul 2012 14:48:50 -0500] rev 17175
merge with stable
Fri, 06 Jul 2012 01:14:02 -0300 convert: make filemap renames consistently override revision renames stable
Wagner Bruna <wbruna@yahoo.com> [Fri, 06 Jul 2012 01:14:02 -0300] rev 17174
convert: make filemap renames consistently override revision renames When the source repository had a revision renaming "$new -> $old", but the filemap a "$old -> $new" rename, the converted revision could use either $new (deleting the file) or $old (keeping the file) when getting the file data, depending on the lexicographical order of those names. So the resulting revision would leave some files untouched (as expected), but delete others arbitrarely.
Fri, 06 Jul 2012 19:34:09 +0200 obsolete: compute extinct changesets
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 06 Jul 2012 19:34:09 +0200] rev 17173
obsolete: compute extinct changesets `extinct` changesets are obsolete changesets with obsolete descendants only. They are of no interest anymore and can be: - exclude from exchange - hidden to the user in most situation - safely garbage collected This changeset just allows mercurial to detect them. The implementation is a bit naive, as for unstable changesets. We better use a simple revset query and a cache, but simple version comes first.
Tue, 10 Jul 2012 01:39:03 +0200 push: refuse to push unstable changesets without force
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 10 Jul 2012 01:39:03 +0200] rev 17172
push: refuse to push unstable changesets without force User should resolve unstability locally before pushing the same way we encourage user to merge locally instead of pushing a new remote head. If we are to push obsolete changeset, at least one set of the pushed set will be either obsolete or unstable. The check is narrowed to only heads.
Fri, 06 Jul 2012 00:18:09 +0200 obsolete: compute unstable changeset
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 06 Jul 2012 00:18:09 +0200] rev 17171
obsolete: compute unstable changeset An unstable changeset is a changeset *not* obsolete but with some obsolete ancestors. The current logic to decide if a changeset is unstable is naive and very inefficient. A better solution is to compute the set of unstable changeset with a simple revset and to cache the result. But this require cache invalidation logic. Simpler version goes first.
Fri, 06 Jul 2012 19:29:10 +0200 revset: add an `obsolete` symbol
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 06 Jul 2012 19:29:10 +0200] rev 17170
revset: add an `obsolete` symbol This predicate matches obsolete changesets. This is a naive implementation to be improved later.
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 +30000 tip