Siddharth Agarwal <sid0@fb.com> [Thu, 19 Nov 2015 10:50:02 -0800] rev 27035
merge.mergestate: compute dirstate action
In upcoming patches we're going to queue these actions up to be applied to the
dirstate at the end.
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 14:22:52 -0800] rev 27034
filemerge: return whether the file was deleted
This is required for change/delete conflict resolution -- see previous patches
for more details.
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 13:55:31 -0800] rev 27033
filemerge: return whether the file is deleted from all other merge tools
This is required for change/delete conflicts -- see the previous patch for more
information.
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 13:52:28 -0800] rev 27032
filemerge: return whether the file is deleted for nomerge internal tools
We're going to support the filemerge code resolving change/delete conflicts in
upcoming patches. Some of these resolutions require that the dirstate be
modified. Modifying the dirstate directly from in here would be (a) a pretty
bad layering violation and (b) wrong because all dirstate removals should
happen before adds. So in this and upcoming patches we're instead going to pass
whether the file is deleted up to merge.mergestate, then in there figure out
what dirstate action needs to be taken.
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 15:46:45 -0800] rev 27031
mergestate: allow storing and retrieving change/delete conflicts
We introduce a new record type, 'C', to indicate change/delete conflicts. This
is a separate record type because older versions of Mercurial will not be able
to handle these conflicts.
We aren't actually storing any change/delete conflicts yet -- that will come in
future patches.
Shubhanshu Agrawal <agrawal.shubhanshu@gmail.com> [Thu, 19 Nov 2015 12:50:10 +0530] rev 27030
strip: changing bookmark argument to be a list
Currently strip works with a single bookmark,
the changes in this patch modifies the strip
extension to accept a list of bookmarks
Shubhanshu Agrawal <agrawal.shubhanshu@gmail.com> [Sun, 15 Nov 2015 21:03:44 +0530] rev 27029
strip: strip a list of bookmarks
Currently strip works with a single bookmark,
the changes in this patch modifies the strip module
to work with a list of bookmarks
Building on this we can take a list of bookmarks as input
and remove all of them in a single go
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 18 Nov 2015 23:23:03 -0800] rev 27028
revset: speed up '_matchfiles'
File matching is done by applying the matcher to all elements in the 'file'
field of all changesets in the repository. This requires to read/parse all
changesets in the repository and do a lot of matching. However about 1/3 of the
time of the function is used to create 'changectx' object and retrieve their
'file' field.
This is far too much overhead so we are skipping the changectx layer and
directly access the data from the changelog. This provide use significant speed
up:
repository: mozilla central 252524 revisions
command: hg perfrevset '_matchfiles("p:browser")'
Before: 15.899687s
After: 10.011705s
Slowdown is even more significant if you have a lot of namespace that slowdown
lookup.
The time is now spent with this approximate repartition:
Matcher: 20%
regexp matching: 10%
changelog.read: 80%
reading revision: 60%
checking hash: 15%
decompression: 15%
reading chunk: 30%
changelog parsing: 20%
decoding to local: 10%
The next easy win is probably to have more of the changelog stack implemented
using the CPython api.
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 15:46:45 -0800] rev 27027
mergestate: handle additional record types specially
This works around a bug in older Mercurial versions' handling of the v2 merge
state.
We also add a bunch of tests that make sure that
(1) we correctly abort when the merge state has an unsupported record type
(2) aborting the merge, rebase or histedit continues to work and clears out the
merge state.
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 23:42:32 -0800] rev 27026
test-resolve.t: remove completely unnecessary line
I have no idea what I was thinking when I wrote this.