Siddharth Agarwal <sid0@fb.com> [Mon, 28 Dec 2015 22:51:37 -0800] rev 27571
merge: while checking for unknown files don't follow symlinks (issue5027)
Previously, we were using Python's native 'os.path.isfile' method which follows
symlinks. In this case, since we're operating on repo contents, we don't want
to follow symlinks.
There's a behaviour change here, as shown by the second part of the added test.
Consider a symlink 'f' pointing to a file containing 'abc'. If we try and
replace it with a file with contents 'abc', previously we would have let it
though. Now we don't. Although this breaks naive inspection with tools like
'cat' and 'diff', on balance I believe this is the right change.
Matt Mackall <mpm@selenic.com> [Thu, 31 Dec 2015 09:55:56 +0100] rev 27570
merge with stable
timeless <timeless@mozdev.org> [Tue, 22 Dec 2015 11:05:56 +0000] rev 27569
tests: add test-check-execute.t
Try to prevent people from adding files with incorrect execute bits
timeless <timeless@mozdev.org> [Wed, 23 Dec 2015 19:07:34 +0000] rev 27568
parents: correct help revset replacements
Implementing `hg parents -r REV FILE` correctly is hard.
The output can be 0, 1, or 2 revs.
First, you can't use parents(), because it sorts its output...
Consider:
echo $a
echo par@rev: `hg log -r "parents($a)" -q`
echo p12@rev: `hg log -r "p1($a)+p2($a)" -q`
echo parents: `hg parents -q -r $a`
(Merge 1 into 0)
3
par@rev: 0:d9612eafe8ec 1:070fe4290d06
p12@rev: 0:d9612eafe8ec 1:070fe4290d06
parents: 0:d9612eafe8ec 1:070fe4290d06
(Merge 4 into 5)
6
par@rev: 4:db73392995c3 5:c26e7dd67644
p12@rev: 5:c26e7dd67644 4:db73392995c3
parents: 5:c26e7dd67644 4:db73392995c3
(Merge 7 into 8)
9
par@rev: 7:d84f47462f70 8:9597bcab36e0
p12@rev: 8:9597bcab36e0 7:d84f47462f70
parents: 8:9597bcab36e0 7:d84f47462f70
You also can't use parents or/p1/p2 alone with a set, as in:
-r "parents(::REV and file(FILE))"
-r "parents(::REV - REV and file(FILE))"
... because each will return all parents for each candidate revision,
and the :: gives too many candidates.
Thus, we need a max and a p1/p2.
Also, anything of this form:
max(::REV - REV and file(FILE))
... is wrong, because max will return only one revision, and for
a proper parents, you need to return two occasionally.
Lastly, it doesn't help that `hg parents -r REV FILE` is buggy
due to a quirk in filelogs.
Here's a repository to consider when evaluating whether your
revset is correct:
$ hg log -G --template '{rev} {files}\n';
@ 10 a
|
o 9 a b
|\
| o 8 a
| |
o | 7 a
| |
+---o 6 b
| |/
| o 5 b
| |
o | 4 b
| |
+---o 3
| |/
+---o 2
| |/
| o 1 b
|
o 0 a
revs 4 and 5 create a conflict.
The conflict is resolved in the same way by both 6 and 9.
You would hope that parents around 9/10 would point to 9,
but `hg parents` will point to 6 due to the aforementioned bug.
Here's the winning solution test script and its output.
echo $a;
echo rp12-max: `hg log -r "max(::p1($a) and file(b)) + max(::p2($a) and file(b))" -q` 2> /dev/null;
echo expected: `hg parents -q -r $a b` 2> /dev/null;
Note that for 10, the output differs, but again, this is because
of the aforementioned bug. The rp12-max output is "correct",
whereas "expected" is just an unfortunate bug. The abort output
is due to something else. I'm not sure why someone thought it
was important to abort to stdio instead of stderr, but that's
really not my problem here.
10
rp12-max: 9:184ebefc2fce
expected: 6:dd558142b03f
9
rp12-max: 5:c26e7dd67644 4:db73392995c3
expected: 5:c26e7dd67644 4:db73392995c3
8
rp12-max: 5:c26e7dd67644
expected: 5:c26e7dd67644
7
rp12-max: 4:db73392995c3
expected: 4:db73392995c3
6
rp12-max: 5:c26e7dd67644 4:db73392995c3
expected: 5:c26e7dd67644 4:db73392995c3
5
rp12-max: 1:070fe4290d06
expected: 1:070fe4290d06
4
rp12-max:
abort: 'b' not found in manifest!
expected:
3
rp12-max: 1:070fe4290d06
expected: 1:070fe4290d06
2
rp12-max: 1:070fe4290d06
expected: 1:070fe4290d06
1
rp12-max:
abort: 'b' not found in manifest!
expected:
0
rp12-max:
abort: 'b' not found in manifest!
expected:
timeless <timeless@mozdev.org> [Mon, 28 Dec 2015 16:01:31 +0000] rev 27567
run-tests: avoid double counting server fails
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Dec 2015 23:50:02 +0900] rev 27566
commandserver: reset state of progress bar per command
A progress bar is normally disabled in command-server session, but chg can
enable it. This patch makes sure the last-print time is measured per command.
Otherwise, progress.delay could be ineffective if a progbar was loaded before
forking worker process.
This patch is corresponding to the following change.
https://bitbucket.org/yuja/chg/commits/2dfe3e90b365
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Dec 2015 23:13:42 +0900] rev 27565
commandserver: do not set nontty flag if channel is replaced by a real file
This prepares for porting the chg server. In chg, a server receives client's
stdio over a UNIX domain socket to override server channels. This is because
chg should behave as if it is a normal hg command attached to tty. "nontty"
is not wanted.
This patch is corresponding to the following change. This doesn't test the
identity of "cin" object because the current version of chg reopens stdio
to apply buffering mode.
https://bitbucket.org/yuja/chg/commits/c48c7aed5fc0
timeless <timeless@mozdev.org> [Tue, 22 Dec 2015 08:00:03 +0000] rev 27564
run-tests: report missing feature for skipped tests
Yuya Nishihara <yuya@tcha.org> [Sat, 26 Dec 2015 16:06:12 +0900] rev 27563
paths: do not process default-push as pushurl of default path (issue5000)
It didn't work because "default-push" and "default" are independent named
items. Without this patch, "hg push default" would push to "default-push"
because paths["default"].pushloc was overwritten by "default-push".
Also, we shouldn't ban a user from doing "hg push default-push" so long as
"default-push" item is defined, not "default:pushurl". Otherwise, he would
be confused by missing "default-push" path.
Tests are included in a patch for stable branch.
Yuya Nishihara <yuya@tcha.org> [Sat, 26 Dec 2015 16:12:28 +0900] rev 27562
push: specify default-push and default as fallback paths
The next patch will remove the "default-push" hack from ui.paths so that
ui.paths["default"].pushurl can be different from "default-push".
Yuya Nishihara <yuya@tcha.org> [Sat, 26 Dec 2015 16:10:39 +0900] rev 27561
paths: make getpath() accept multiple defaults
This is necessary to handle "default-push" and "default" as fallback items.
We can't apply the same rule as "default:pushurl" because "default-push" is
a valid named path.
This series is for default branch. I have a simpler patch for stable.
timeless <timeless@mozdev.org> [Thu, 24 Dec 2015 19:32:14 +0000] rev 27560
check-code: improve test-check-code error diffs
Whenever check-code finds something wrong, the diffs it
generated were fairly hard to read.
The problem is that check-code before this change
would list files that were white listed using
no- check- code but without a glob marker.
Whereas, the test-check-code.t expected output has
no-che?k-code (glob) in order to avoid having itself
flagged as a file to skip.
Thus, in addition to any lines relating to things you
did wrong, all of the white-listed files are listed as
changed.
There is no reason for things to be this painful.
This change makes the output from check-code.py match
the expected output in test-check-code.t
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 24 Dec 2015 10:16:30 -0800] rev 27559
destutil: use scmutil.revrange for desthistedit (issue5001)
This allows user aliases to be expanded. It also prevents the
user-provided revset from being treated as a revset expression.
Matt Mackall <mpm@selenic.com> [Fri, 18 Dec 2015 13:53:50 -0600] rev 27558
pull: make a single call to obsstore.add (issue5006)
Prior to this, a pull of 90k markers (already known locally!) was
making about 2000 calls to obsstore.add, which was repeatedly building
a full set of known markers (in addition to other transaction
overhead). This quadratic behavior accounted for about 50 seconds of a
70 second no-op pull. After this change, we're down to 20 seconds.
While it would seem simplest to just cache the known set for
obsstore.add, this would also introduce issues of correct cache invalidation.
The extra pointless transaction overhead would also remain.