In order to support sub-topics, we need to support linking to a full
topic name while displaying the base topic name. Change the {helpentry}
template to grab the display name from an optional seperate variable
(which will be defined in a future patch).
We now have sub-topics in the help system. The "helptopics" template
serves as a mechanism for displaying an index of help topics.
Previously, it was only used to show the top-level list of help topics,
which includes special groupings of topics.
In the near future, we'll adapt "helptopics" for showing the index
of sub-topics. In this patch, we optionally render {earlycommands} and
{othercommands} since they aren't present on sub-topics.
Before this patch, when rebasing a set of obsolete revisions that were plain
pruned or already present in the destination, we were displaying:
abort: no matching revisions
This was not very helpful to understand what was going on, instead we replace
the error message by:
abort: all requested changesets have equivalents or were marked as obsolete
(to force the rebase, set the config experimental.rebaseskipobsolete to False)
This diff implements the standard dict copy() method for lrucachedicts, which
will be used in the pushrebase extension to make a copy of the manifestcache.
This effectively backs out 163c899d1e46 and f44b0edaab90.
We can't handle "default-push" just like "default:pushurl" because it is a
stand-alone named path. Instead, I have two ideas to work around the issue:
a. two defaults: getpath(dest, default=('default-push', 'default'))
b. virtual path: getpath(dest, default=':default')
(a) is conservative approach and will have less trouble, but callers have
to specify they need "default-push" or "default". (b) generates hidden
":default" path from "default" and "default-push", and callers request
":default". This will require some tricks and won't work if there are
conflicting sub-options valid for both "pull" and "push".
I'll take (a) for default branch. This patch should NOT BE MERGED to default
except for tests because it would break handling of "pushurl" sub-option.
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:
On some servers, python curses support is disabled. This patch not only fixes
that but provides a fallback on other machines (e.g. Windows) when curses is
not found.
The previous code was actually flawed logic and relied on wcurses throwing an
ImportError which demandimport wouldn't throw. So, this patch also fixes that
problem.
Instead of blindly trusting the user's experimental.crecord, we use checkcurses
to abstract that logic so that we can handle the case where python was not
built with curses.
Not only does this improve fragility with 'if os.name == ...' it will help
future patches enable the behavior to fallback to use plain record when curses
is unavailable (e.g. python compiled without curses support).
Before this patch, "hg qimport -r REV" fails, if the summary line of
description of REV doesn't contain any alpha-numeric bytes.
In this case, all bytes in the summary line 'title' are dropped from
'namebase' by the code path below.
namebase = re.sub('[\s\W_]+', '_', title.lower()).strip('_')
'makepatchname()' immediately returns this empty string as valid patch
name, because patch name conflicting against empty string never
exists.
Then, "hg qimport -r REV" is aborted at creation of patch file with
empty filename.
This situation isn't so rare. For example, ordinary texts in Japanese
often consist of non alpha-numeric bytes in UTF-8.
This patch makes 'makepatchname()' use fallback patch name if the
summary line of imported revision doesn't contain any alpha-numeric
bytes.
Revlogs were recently refactored to open file handles in "a+" and use a
persistent file handle for reading and writing. This drastically
reduced the number of file handles being opened.
Unfortunately, it appears that some versions of Solaris lose the file
offset when performing a write after the handle has been seeked.
The simplest workaround is to seek to EOF on files opened in a+ mode
before writing to them, which is what this patch does.
Ideally, this code would exist in the vfs layer. However, this would
require creating a proxy class for file objects in order to provide a
custom implementation of write(). This would add overhead. Since
revlogs are the only files we open in a+ mode, the one-off workaround
in revlog.py should be sufficient.
This patch appears to have little to no impact on performance on my
Linux machine.
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
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
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.
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.
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
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.
This came up before, but the tests in check-code.py don't find -U (only -u)
and they don't work when the diff is inside a shell function. This fixes
the offending tests and beefs up check-code.py.
Danek's patch will help us avoid spurious test breakages on
Solaris. This test wasn't broken on Solaris because of the grep(1)
use, but it will upset check-code. Use cmp to silence check-code since
it doesn't matter.
currently "subscribe to atom feed" link in file log page is as follows.
/atom-log/[revision]/[file]
This is invalid, because we could not get newer commit feed than [revision].
To fix this, atom-log feed url should be the following style.
atom-log/tip/[file]
This patch adds a comment making it clear that we should hold a lock before
calling repair.strip. The wording is the same than what we have for
obsolete.createmarkers
PyPy's implementation of __import__ differs subtly from that of CPython.
If invoked without a name or fromlist, it throws an ImportError,
whereas CPython returns a reference to the level-appropriate importing
package.
Here, we achieve the same behaviour by hand.
