Sun, 11 Oct 2015 23:54:40 -0700 test-resolve.t: add some output to show order of operations
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 23:54:40 -0700] rev 26619
test-resolve.t: add some output to show order of operations This basically shows the behavior of resolve with multiple files. An upcoming behavior change will cause this output to also change.
Sun, 11 Oct 2015 21:56:39 -0700 merge.mergestate: perform all premerges before any merges (BC)
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 21:56:39 -0700] rev 26618
merge.mergestate: perform all premerges before any merges (BC) We perform all that we can non-interactively before prompting the user for input via their merge tool. This allows for a maximally consistent state when the user is first prompted. The test output changes indicate the actual behavior change happening.
Sun, 11 Oct 2015 20:12:12 -0700 merge: introduce a preresolve function
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 20:12:12 -0700] rev 26617
merge: introduce a preresolve function The section of code that writes out the version of the file cached in the merge state should only be run at preresolve time. This is so that if the premerge keeps around conflict markers, those don't get overwritten before the main merge.
Sun, 11 Oct 2015 18:37:54 -0700 merge.mergestate._resolve: also return completed status
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 18:37:54 -0700] rev 26616
merge.mergestate._resolve: also return completed status We'll need this for a new 'preresolve' function we're adding.
Sun, 11 Oct 2015 18:29:50 -0700 merge.mergestate: add a wrapper around resolve
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 18:29:50 -0700] rev 26615
merge.mergestate: add a wrapper around resolve The resolve function will be broken up into separate pre-resolve and resolve steps.
Fri, 09 Oct 2015 13:54:52 -0700 simplemerge: move conflict warning message to filemerge
Siddharth Agarwal <sid0@fb.com> [Fri, 09 Oct 2015 13:54:52 -0700] rev 26614
simplemerge: move conflict warning message to filemerge The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
Sun, 11 Oct 2015 15:04:00 -0700 filemerge: clean up some dead code
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 15:04:00 -0700] rev 26613
filemerge: clean up some dead code We now exit early if we do a premerge, so extra checks are no longer necessary.
Mon, 12 Oct 2015 14:15:04 -0400 run-tests: add b-prefix on two strings to fix python3 support
Augie Fackler <augie@google.com> [Mon, 12 Oct 2015 14:15:04 -0400] rev 26612
run-tests: add b-prefix on two strings to fix python3 support
Sun, 11 Oct 2015 20:47:14 -0700 filemerge: break overall filemerge into separate premerge and merge steps
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 20:47:14 -0700] rev 26611
filemerge: break overall filemerge into separate premerge and merge steps This means that in ms.resolve we must call merge after calling premerge. This doesn't yet mean that all premerges happen before any merges -- however, this does get us closer to our goal. The output differences are because we recompute the merge tool. The only user-visible difference caused by this patch is that if the tool is missing we'll print the warning twice. Not a huge deal, though.
Sun, 11 Oct 2015 20:04:40 -0700 filemerge: only copy to backup during premerge step
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 20:04:40 -0700] rev 26610
filemerge: only copy to backup during premerge step The premerge might leave the original file in an unclean state. Therefore it's important to only copy the file in the beginning.
Sun, 11 Oct 2015 20:02:53 -0700 filemerge: only print out "merging f" output at premerge step
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 20:02:53 -0700] rev 26609
filemerge: only print out "merging f" output at premerge step We're soon going to call this function twice, once for premerge and once for merge. This makes sure the "merging" output only gets printed during the premerge step.
Thu, 08 Oct 2015 00:19:20 -0700 filemerge: deindent the parts of filemerge outside the try block
Siddharth Agarwal <sid0@fb.com> [Thu, 08 Oct 2015 00:19:20 -0700] rev 26608
filemerge: deindent the parts of filemerge outside the try block It is no longer necessary to indent these parts.
Sun, 11 Oct 2015 20:47:04 -0700 filemerge: introduce a premerge flag and function
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 20:47:04 -0700] rev 26607
filemerge: introduce a premerge flag and function This flag will let us get to our overall goal of performing all premerges before any merges.
Sun, 11 Oct 2015 12:56:21 -0700 filemerge: also return whether the merge is complete
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 12:56:21 -0700] rev 26606
filemerge: also return whether the merge is complete In future patches, we'll pause merges after the premerge step. After the premerge step we'll return complete = False.
Sun, 11 Oct 2015 12:31:08 -0700 filemerge: add a wrapper around the filemerge function
Siddharth Agarwal <sid0@fb.com> [Sun, 11 Oct 2015 12:31:08 -0700] rev 26605
filemerge: add a wrapper around the filemerge function We'll introduce a separate premerge function that calls the same code.
Fri, 09 Oct 2015 01:19:37 +0200 context: don't hex encode all unknown 20 char revision specs (issue4890)
Mads Kiilerich <madski@unity3d.com> [Fri, 09 Oct 2015 01:19:37 +0200] rev 26604
context: don't hex encode all unknown 20 char revision specs (issue4890) d3908c911d5e introduced nice hexified display of missing nodes. It did however also make missing 20 character revision specifications be shown as hex - very confusing. Users are often wrong and somehow specify revisions that don't exist. Nodes will however rarely be missing ... and they will only look like a user provided revision specification and be all ascii in 1 of 4*10**9. With this change, missing revisions will only be hexified if they really look like binary nodes. This change will thus improve the error reporting UI in the common case and only very rarely make it confusing in the opposite direction of how it was before.
Mon, 12 Oct 2015 00:45:24 -0700 discovery: put trivial branch first
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 12 Oct 2015 00:45:24 -0700] rev 26603
discovery: put trivial branch first Having the simple and tiny branch of the conditional first help readability. The "else" that appears after a screen of code is harder to relate to a conditional.
Fri, 09 Oct 2015 15:31:50 -0700 shelve: rename 'publicancestors' to something accurate (issue4737)
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:31:50 -0700] rev 26602
shelve: rename 'publicancestors' to something accurate (issue4737) That function is actually not returning public ancestors at all. This is pointed by the second line of the docstring... The bundling behavior was made correct in a5141977198d but with confusion remaining regarding what each function was doing. This close issue4737, because this highlight that shelve is actually -not- bundling too much data (this was actually properly tested).
Fri, 09 Oct 2015 12:30:46 -0500 makefile: add wheel build target
Nathan Goldbaum <ngoldbau@ucsc.edu> [Fri, 09 Oct 2015 12:30:46 -0500] rev 26601
makefile: add wheel build target
Fri, 09 Oct 2015 12:25:51 -0500 setup: import setup from setuptools if FORCE_SETUPTOOLS is set
Nathan Goldbaum <ngoldbau@ucsc.edu> [Fri, 09 Oct 2015 12:25:51 -0500] rev 26600
setup: import setup from setuptools if FORCE_SETUPTOOLS is set This should allow easier experimentation with using setuptools in mercurial's build automation, without breaking anything that currently depends on distutils behavior
Mon, 12 Oct 2015 14:46:51 +0100 hgweb: remove obsolete -webkit-border-radius property
Gijs Kruitbosch <gijskruitbosch@gmail.com> [Mon, 12 Oct 2015 14:46:51 +0100] rev 26599
hgweb: remove obsolete -webkit-border-radius property
Mon, 12 Oct 2015 15:20:04 +0800 monoblue: add a link to the latest file revision
Anton Shestakov <av6@dwimlabs.net> [Mon, 12 Oct 2015 15:20:04 +0800] rev 26598
monoblue: add a link to the latest file revision For reference, this was added to paper/coal in bb00a159e594 and to gitweb in b3b57ecbda50.
Fri, 09 Oct 2015 15:44:00 -0700 discovery: reference relevant bug in the faulty code
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:44:00 -0700] rev 26597
discovery: reference relevant bug in the faulty code We extend the comment about this code flaw with more code flaw.
Fri, 09 Oct 2015 15:37:05 -0700 discovery: fix a typo in a comment
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 15:37:05 -0700] rev 26596
discovery: fix a typo in a comment The idea here is that the code is imperfect, not that it is impossible to get something behaving properly.
Fri, 09 Oct 2015 14:59:37 -0700 getsubset: get the unpacker version from the bundler
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 09 Oct 2015 14:59:37 -0700] rev 26595
getsubset: get the unpacker version from the bundler The current setup requires to pass both a packer and, optionally, the version of the unpacker. This is confusing and error prone as the two value cannot mismatch. Instead, we simply grab the version from the packer. This fixes a bug where requesting a cg2 from 'hg bundle' were reported as changegroup 1. I should have caught that in the initial changeset but I missed it somehow.
Mon, 12 Oct 2015 15:42:32 +0300 test-convert-cvs: add sleep so cvs notices changes
Emanuele Giaquinta <emanuele.giaquinta@gmail.com> [Mon, 12 Oct 2015 15:42:32 +0300] rev 26594
test-convert-cvs: add sleep so cvs notices changes This change makes the test pass on gcc112.fsffrance.org.
Wed, 07 Oct 2015 11:33:52 +0300 cvsps: fix computation of parent revisions when log caching is on
Emanuele Giaquinta <emanuele.giaquinta@gmail.com> [Wed, 07 Oct 2015 11:33:52 +0300] rev 26593
cvsps: fix computation of parent revisions when log caching is on cvsps computes the parent revisions of log entries by walking the cvs log sorted by (rcs, revision) and by iteratively maintaining a 'versions' dictionary which maps a (rcs, branch) pair onto the last revision seen for that pair. When log caching is on and a log cache exists, cvsps fails to set the parent revisions of new log entries because it does not iterate over the log cache in the parents computation. A complication is that a file rcs can change (move to/from the attic), with respect to its value in the log cache, if the file is removed/added back. This patch adds an iteration over the log cache to update the rcs of cached log entries, if changed, and to properly populate the 'versions' dictionary.
Tue, 06 Oct 2015 16:26:20 -0500 dirstate: batch calls to statfiles (issue4878)
Matt Mackall <mpm@selenic.com> [Tue, 06 Oct 2015 16:26:20 -0500] rev 26592
dirstate: batch calls to statfiles (issue4878) This makes it more interruptible.
Sun, 11 Oct 2015 18:30:47 +0900 parsers: fix infinite loop or out-of-bound read in fm1readmarkers (issue4888)
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Oct 2015 18:30:47 +0900] rev 26591
parsers: fix infinite loop or out-of-bound read in fm1readmarkers (issue4888) The issue4888 was caused by 0-length obsolete marker. If msize is zero, fm1readmarkers() never ends. This patch adds several bound checks to fm1readmarker(). Therefore, 0-length and invalid-size marker should be rejected.
Sun, 11 Oct 2015 18:41:41 +0900 parsers: read sizes of metadata pair of obsolete marker at once
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Oct 2015 18:41:41 +0900] rev 26590
parsers: read sizes of metadata pair of obsolete marker at once This will make it easy to implement bound checking. Currently fm1readmarker() has no protection for corrupted obsstore and can cause infinite loop or out-of-bound reads.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip