Sat, 16 Nov 2013 15:54:41 -0500 largefiles: stylistic cleanup of filemerge
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:54:41 -0500] rev 20298
largefiles: stylistic cleanup of filemerge
Sat, 16 Nov 2013 15:46:29 -0500 largefiles: show hashes before prompting for conflict resolution
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20297
largefiles: show hashes before prompting for conflict resolution The largefile hashes are mostly an implementation detail, but they are "leaked" in several places anyway, and showing the hashes is better than not giving the user any information about the options in the prompt. The hashes are long, but it is largefile hashes and it would thus be confusing to shorten them.
Sat, 16 Nov 2013 15:46:29 -0500 largefiles: don't try to explain rename history before prompt for conflicts
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20296
largefiles: don't try to explain rename history before prompt for conflicts Before it tried to explain the exact situation when merging moved largefiles. That do not happen for normal merges and is not more relevant for largefiles than for normal files. It is unneeded complexity - remove it.
Sat, 16 Nov 2013 15:46:29 -0500 largefiles: drop redundant special handling of merges of renames
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20295
largefiles: drop redundant special handling of merges of renames It is unclear what cases this was supposed to cover but it do no longer seem relevant.
Sat, 16 Nov 2013 15:46:29 -0500 diff: search beyond ancestor when detecting renames
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20294
diff: search beyond ancestor when detecting renames This removes an optimization that was introduced in 91eb4512edd0 but was too aggressive - as indicated by how it changed test-mq-merge.t . We are walking filelogs to find copy sources and we can thus not be sure to hit the base revision and find the renamed file there - it could also be in the first ancestor of the base ... in the filelog. We are walking the filelog and can thus not easily know when we hit the first ancestor of the base revision and which filename to look for there. Instead, we use _findlimit like mergecopies do: The lower bound for how far we have to go is found from the lowest changelog revision that is an ancestor of only one of the compared revisions. Any filelog ancestor with a revision number lower than that revision will be the ancestor of both compared revisions, and there is thus no reason to go further back than that.
Tue, 14 Jan 2014 13:38:16 -0800 cat: increase perf when catting single files
Durham Goode <durham@fb.com> [Tue, 14 Jan 2014 13:38:16 -0800] rev 20293
cat: increase perf when catting single files Special case the single file case in hg cat. This allows us to avoid parsing the manifest, which shaves 15% off hg cat perf. This is worth it, since automation often uses hg cat for retrieving single files.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip