Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 20:56:53 -0800] rev 23638
merge: let bid merge work on the file->action dict
By moving the conversion from the file->action dict after the bid
merge code, bid merge can be simplified a little.
A few tests are affected by this change. Where we used to iterate over
the actions first in order of the action type ('g', 'r', etc.) [1], we
now iterate in order of filename. This difference affects the order of
debug log statements.
[1] And then in the non-deterministic order of files in the manifest
dictionary (the order returned from manifest.diff()).
Martin von Zweigbergk <martinvonz@google.com> [Mon, 08 Dec 2014 13:24:10 -0800] rev 23637
merge: write manifestmerge() using dictionary with entry per file
In the same vein as 38e55e55ae4d (largefiles: rewrite merge code using
dictionary with entry per file, 2014-12-09), rewrite manifestmerge()
itself as dictionary with the filename as key. This will let us
simplify some of the other code in merge.py and eventually drop the
conversion in the largefiles code.
No difference in speed could be detected (well within the noise level
when run in Mozilla repo).
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 17 Dec 2014 12:21:07 -0800] rev 23636
repoview: backout ced3ecfc2e57
Monkey patching repoview does not really work and making it really work will
be really hard. So we better have it broken without complexity than broken with
extra complexity.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 17 Dec 2014 12:19:33 -0800] rev 23635
largefile: explain why no monkey patching on a repoview
The comment requested for investigations, here they are.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 17 Dec 2014 12:10:16 -0800] rev 23634
largefile: backout ca54fb3d71ce
The hack for method monkey patching on repoview has been ruled out as
fragile, so we are rolling it back. We'll expand the explanation in the next
changeset.
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 12:33:17 -0800] rev 23633
incoming: handle phases the same as pull
Now that bundlerepo can move phases safely, 'hg incoming' can share its phase
handling code with pull to better reflect what would actually show up.
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 12:22:43 -0800] rev 23632
bundlerepo: retract phase boundary
This patch makes bundrepo retract the phase boundary for new commits to 'draft'
status, which is consistent with the behavior of 'hg unbundle'. The old
behavior was for commits to appear with the same phase as their nearest
ancestor in the base repository.
This affects several classes of operation:
* Inspecting a bundle with the -B flag
* Treating a bundle file as a peer (old: everything public, new: everything draft)
* Incoming command (neither old or new behavior is sensible -- fixed in next patch)
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 11:38:48 -0800] rev 23631
bundlerepo: implement safe phasecache
This patch makes bundlerepo use a subclass of phasecache that will allow phase
boundaries to be moved around, but will never write them to the underlying
repository.
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 11:30:10 -0800] rev 23630
localrepo.__getitem__: add slicing support
This allows the python slice syntax to be used with revision numbers when
indexing into a repository, such as repo[8:]
Siddharth Agarwal <sid0@fb.com> [Tue, 16 Dec 2014 14:34:53 -0800] rev 23629
ignore: resolve ignore files relative to repo root (issue4473) (BC)
Previously these would be considered to be relative to the current working
directory. That behavior is both undocumented and doesn't really make sense.
There are two reasonable options for how to resolve relative paths:
- relative to the repo root
- relative to the config file
Resolving these files relative to the repo root matches existing behavior with
hooks. An earlier discussion about this is available at
http://mercurial.markmail.org/thread/tvu7yhzsiywgkjzl.
Thanks to Isaac Jurado <diptongo@gmail.com> for the initial patchset that
spurred the discussion.