This addresses the bug described in issue4405: when obsolescence markers are
enabled, amending a commit with a file move can lead to the copy information
being lost.
However, the bug is more general and can be reproduced without obsmarkers as
well, as demonstracted by Pierre-Yves and put into the updated test.
Specifically, graph topology divergences between the filelogs and the changelog
can cause copy information to be lost during amends.
If an exception is raised during a bundle2 part payload generation it is now
recorded in the bundle. If such exception occurs, we capture it, transmit an
abort exception through the bundle, cleanly close the current part payload and
raise it again. This allow to generate valid bundle even in case of exception so
that the consumer does not wait forever for a dead producer. This also allow to
raise the exception during unbundling at the exact point it happened during
bundling make debugging easier.
The transaction backupfiles logic was broken for 'hg recover'. The file format
is XXX\0XXX\0YYY\0YYY\0 but the parser did a couple things wrong. 1) It went one
step beyond the final \0 and tried to read past the end of the array. 2)
array[i:i+1] returns a single item, instead of two items as intended.
Added a test to catch it, which turns out to be the first actual 'hg recover'
test.
The recent optimization of "and" operation relies on the assumption that
the rhs set does not contain invalid revisions. So rev() has to remove
invalid revisions.
This is still faster than using `.filter(lambda r: r == l)`.
revset #0: rev(25)
0) wall 0.026341 comb 0.020000 user 0.020000 sys 0.000000 (best of 113)
1) wall 0.000038 comb 0.000000 user 0.000000 sys 0.000000 (best of 66567)
2) wall 0.000062 comb 0.000000 user 0.000000 sys 0.000000 (best of 43699)
(0: 428fa22fb2d1^, 1: 3.2-rc, 2: this patch)
Before this patch, "test-context.py" fails on Windows environment,
because "diff" output contains unexpected "\r" character.
Opening the target file in text mode causes this automatic end-of-line
conversion.
Changeset d735f8a82023 introduced "showing prompt choice if input is
not a tty but is forced to be interactive" and adjusted expected
output in test-record.t.
But some tests for no-execbit platform (= Windows) were not adjusted
by d735f8a82023.
This causes unexpected failure of test-record on Windows environment.
This patch adds below to prompt lines for such tests:
- prompt choice at the end of prompt line, and
- empty line after prompt line
The problem in commandserver was addressed by 766cfbe766dc, but it is tricky
to reuse ui.nontty option to disable echo back. Instead, this patch introduces
new option to enable echoing of prompt response.
Prompt echoing is changed to be off by default, which should avoid possible
breakage of output parsing in user scripts.
For now, this option is undocumented because it exists for internal use.
Hooks that run after the transaction need to be able to touch the
repository. So we need to run them after the lock release. This is
similar to what the "changegroup" hook is doing in the
`addchangegroup` function.
Hidden changesets are by far the most common error case and is the only one[1]
that can reach the user. We move to a friendlier message with a hint about how
to access the data anyway. We should probably point to a help topic instead but
we do not have such a topic yet.
Example of the new output
abort: hidden revision '4'!
(use --hidden to access hidden revisions)
[1] Actually, filtering from "served" can also reach the user during certain
exchange operations.
This will help user to debug. A more precise message will be issued
for the most common case ("visible" filter) in the next changesets.
example output:
- abort: filtered revision '4'!
+ abort: filtered revision '4' (not in 'visible' subset)!
The hack for using certificate store in addition to the provided CAs resides in
Apple's OpenSSL. Apple's own Pythons will use it, but other custom built
Pythons might use a custom built OpenSSL without that hack and will fail when
exposed to the dummy cacert introduced in ee8b7fe5e119.
There do not seem to be a simple way to check from Python if we are using a
patched OpenSSL or if it is an Apple OpenSSL.
Instead, check if the Python executable resides in /usr/bin/python* or in
/System/Library/Frameworks/Python.framework/ and assume that all Pythons found
there will be native Pythons using the patched OpenSSL.
Custom built Pythons will not get the benefit of using the CAs from the
certificate store.
The 'status --rev' code is not very well tested, which has bitten us
as recently as in issue4321. Let's add some more tests, some of which
uncover bugs. Remove the few existing tests that are now covered in a
more thorough and consistent way.
Because unix-mode server forks child process per connection, client does not
know the pid of the server that will handle requests. The pid is necessary
to interrupt hung process:
1. client connects to socket server
2. server accepts the connection, forks, and tells pid
3. client requests "runcommand pull"
.. hung ..
4. client sends SIGINT to the (forked) server
5. server returns from I/O wait
Note that getsockopt(SO_PEERCRED) of Linux cannot be used because the server
fork()s after accept().
Consider a hypothetical bug in the release function that causes it to raise an
exception. Also consider the bisect command, which saves its state in a finally
clause. Saving the state requires acquiring the wlock.
If we don't unlink the lockfile when the exception is thrown, we'll try to
acquire the wlock again. We're going to try and acquire a lock again while our
old lockfile is on disk. The PID on disk is our own, and of course we're still
running, so we won't take over the lock. Hence we'll be stuck waiting for a
lock that we left behind ourselves.
To avoid this, always unlink the lockfile. This preserves the invariant that
self.held > 0 is equivalent to the lockfile existing on disk.
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
The '-y' in 'hg update -y' was once needed to answer questions about
modify/delete conflicts. That is no longer needed, so remove the '-y'
and the comment justifying its use.
We already have a test for 'hg resolve -m' when there is no merge in
progress. Add one for 'hg resolve --all' as well.
Also add tests for both --all and -m when there is a merge without
conflicts in progress. They should both be successful, just as if
there had been conflicts that had been marked resolved. However, that
is currently broken, so mark the tests broken for now. The behavior
will be fixed in a later patch.
We capture FilteredxxxError and issue a FilteredRepoLookupError instead with a
sightly different messsge. The message will likely get more improvement in the
future.
error: filtered revision '4'
We are changing all integers that denote the size of a chunk to read to int32.
There are two main motivations for that.
First, we change everything to the same width (32 bits) to make it possible for
a reasonably agnostic actor to forward a bundle2 without any extra processing.
With this change, this could be achieved by just reading int32s and forwarding
chunks of the size read. A bit a smartness would be logic to detect the end of
stream but nothing too complicated.
Second, we need some capacity to transmit special information during the bundle
processing. For example we would like to be able to raise an exception while a
part is being read if this exception happend while this part was generated.
Having signed integer let us use negative numbers to trigger special events
during the parsing of the bundle.
The format is renamed for B2X to B2Y because this breaks binary
compatibility. The B2X format support is dropped. It was experimental to
allow this kind of things. All elements not directly related to the binary
format remain flagged "b2x" because they are still compatible.
We would like exceptions raised during the generation process to be gracefully
handled on the receiver side. We add a test for it. It shows that we are not
doing it yet.
We need a wider set of hooks to process all the changes that happened during the
pull transaction. We reuse the experimental `b2x-transactionclose` hook set
from server's unbundle for consistency. This hook is experimental and will not
remains as-is forever, but this will open the door for experimentation in 3.2.
Typical use case of 'unix' mode is a background hg daemon.
$ hg serve --cmdserver unix --cwd / -a /tmp/hg-`id -u`.sock
Unlike 'pipe' mode in which parent process keeps stdio channel, 'unix' server
can be detached. So clients can freely connect and disconnect from server,
saving Python start-up time.
It might be better to write "--cmdserver socket -a unix:/sockpath" instead
of "--cmdserver unix -a /sockpath" in case hgweb gets the ability to listen
on unix domain socket.
The source information can, should be applied once when opening the transaction
for the pull. This will lets element processed within a bundle2 be aware of them
and open the door to running a set of hooks when closing this pull transaction.
This is similar to what is done in server's unbundle call.
We store the source and url of the current data into `transaction.hookargs` this
let us inherit it from upper layers that may have created a much wider
transaction. We have to modify bundle2 at the same time to register the source
and url in the transaction. We have to do it in the same patch otherwise, the
`addchangegroup` call would fill these values and the hook calling will crash
because of the duplicated 'source' and 'url' arguments passed to the hook call.
The transaction is now carrying hook-related informations. So we use it to
retrieve the `node` argument. This will also carry around all kinds of other useful
informations (like: "are we in a bundle2 processing")
A bundle2 may contain multiple parts adding changegroups, in which case there
are multiple operation records for changegroups, each with its own return
value. Those multiple return values are aggregated in a single cgresult value
for the whole operation.
As can be seen in the associated test case, the situation with hooks is not
really the best, but without deeper thoughts and changes, we can't do much
better. Hopefully, things will be improved before bundle2 is enabled by default.
In the meanwhile, multiple changegroups is not expected to be in widespread
use, and even less expected to be used for pushes. Also, not many clients
cloning or pulling bundle2 with multiple changesets are not expected to have
changegroup hooks anyways.
addchangegroup creates a runhook function that is used to invoke the
changegroup and incoming hooks, but at the time the function is called,
the contents of hookargs associated with the transaction may have been
modified externally. For instance, bundle2 code affects it with
obsolescence markers and bookmarks info.
It also creates problems when a single transaction is used with multiple
changegroups added (as per an upcoming change), whereby the contents
of hookargs are that of after adding a latter changegroup when invoking
the hook for the first changegroup.
There are currently two different tests using roughly the same code to
create temporary scripts acting as HTTP servers. As there is going to
be at least one more in an upcoming change, factor those out in a
standalone dumbhttp.py script.
This test actually used the obs.py file as part of the test, so we need to fix
up the test a little more than usual to work with the new obsolete option flags.
The obsolete._enabled flag has become a config option. This updates all but one
of the tests to use the minimal number of flags necessary for them to pass. For
most tests this is just 'createmarkers', for a couple tests it's
'allowunstable', and for even fewer it's 'exchange'.
Previously, obstore read the obsolete._enabled flag to determine whether to
allow writes to the obstore. Since obsolete._enabled will be moving into a repo
specific config, we can't read it globally, and therefore must pass the
information into the constructor.
We also track execution of the changegroup hook. The important information here
is to make sure the information that the transaction was processing a bundle2 is passed to
hook. This will let most hooks disable themselves while waiting for the hook
concluding bundle2 processing (the one we discovered to be not called for
pull in the previous changesets).
We can notice that this transaction wide hook is only happening during push and
it is missing changegroup-related information. We'll want to fix this but this
is not what this patch is about.
This is preparation for removing open-coded rebase/graft operations.
As a side-effect, this exposes proper renames in the working copy when
there are conflicts, which shows up in test-shelve.t.
Lazy revset broke the ordering of the `or` revset. We now stop assuming that
two ascending revset are combine into an ascending one.
Behavior in 3.0:
3:4 or 2:5 == [2, 3, 4, 5]
Behavior in 2.9:
3:4 or 2:5 == [3, 4, 2, 5]
We are adding a test for it.
For unclear reason, the performance `or` revset with expensive filter are
getting even worse than they used to be. This is probably caused by extra
uncached containment check or iteration.
revset #9: author(lmoscovicz) or author(mpm)
before) wall 3.487583 comb 3.490000 user 3.490000 sys 0.000000 (best of 3)
after) wall 4.481486 comb 4.480000 user 4.470000 sys 0.010000 (best of 3)
revset #10: author(mpm) or author(lmoscovicz)
before) wall 3.164839 comb 3.170000 user 3.160000 sys 0.010000 (best of 3)
after) wall 4.574965 comb 4.570000 user 4.570000 sys 0.000000 (best of 3)
We use the & operator to combine with subset (since this is more likely to be
optimised than filter) and we enforce the sorting of the result. Without this
enforced sorting, we may result in a different iteration order than the set
_descendent was computed from.
This reverts a bad `test-glog.t` change from 7904906883bd.
Another side effect is that `test-mq.t` shows `qparent::` including `-1` if
`qparent is -1`. This sound like a positive change.
This has good and bad impacts on the benchmarks, here is a good ones:
revset: 0::
before) wall 0.045489 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
after) wall 0.034330 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
revset: roots((0::) - (0::tip))
before) wall 0.134090 comb 0.140000 user 0.140000 sys 0.000000 (best of 63)
after) wall 0.128346 comb 0.130000 user 0.130000 sys 0.000000 (best of 69)
revset: ::p1(p1(tip))::
before) wall 0.143892 comb 0.140000 user 0.140000 sys 0.000000 (best of 55)
after) wall 0.124502 comb 0.130000 user 0.130000 sys 0.000000 (best of 65)
revset: roots((0:tip)::)
before) wall 0.204966 comb 0.200000 user 0.200000 sys 0.000000 (best of 43)
after) wall 0.184455 comb 0.180000 user 0.180000 sys 0.000000 (best of 47)
Here is a bad one:
revset: (20000::) - (20000)
before) wall 0.009592 comb 0.010000 user 0.010000 sys 0.000000 (best of 222)
after) wall 0.029837 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
This test, written after 3.0, is relying on addset being enforced ascending if
both side are ascending. We are about to restore the ordering to 2.9 behavior
(elements are ordered in the order they are specified). We fix the test before
fixing the order.
If a merge is attempted when another merge is already ongoing, we give
the message "outstanding uncommitted merges". Many other commands
(such as backout, rebase, histedit) give the same message in singular
form. Since the singular form also seems to make more sense, let's use
that for 'hg merge' as well.
Diff generation didn't really fail, it recognized that an hg serve server has
failed to start, and thus skipped the diff generation intentionally.
The most common reason for a server to fail to start is that the port was
already in use, so output HGPORT as well, to help finding it (since pgrep -f
'hg serve' is not sufficient, if the command line is something like 'hg -R main
serve')
Without this change, --first causes currently-running tests to explode
in violent and surprising ways when their temporary directory gets
cleaned up. Now we just suppress failure messages from non-first
failures when running in --first mode.
When unshelving and facing a conflict, if we resolve all conflicts in
favour of the committed changes instead of the shelved changes, then
the ensuing implicit rebase is a no-op. That is, there is nothing to
rebase. In this case, there are no extra intermediate shelve commits
to strip either. Prior to this change, the commit being unshelved to
would be marked for destruction in a rather catastrophic way.
The relevant part of the test case failed as follows:
$ hg unshelve -c
unshelve of 'default' complete
$ hg diff
warning: ignoring unknown working parent 33f7f61e6c5e!
diff --git a/a/a b/a/a
new file mode 100644
--- /dev/null
b/a/a
@@ -0,0 1,3 @@
a
c
x
$ hg status
warning: ignoring unknown working parent 33f7f61e6c5e!
M a/a
? a/a.orig
? foo/foo
$ hg summary
warning: ignoring unknown working parent 33f7f61e6c5e!
parent: -1:000000000000 (no revision checked out)
branch: default
commit: 1 modified, 2 unknown (new branch head)
update: 4 new changesets (update)
With this change, this test case now passes.
This just copies the same local sample hgrc, except it sets the
default path to the repo it was cloned from.
This is cut-and-paste from the local sample hgrc, but I think it's
acceptable, since the two pieces of code are right next to each other
and they're small. There is danger of them going out of synch, but it
would complicate the code too much to get rid of this C&P.
I also add ui as an import to hg.py, but with demandimport, this
should not be a noticeable performance hit.
Since 266cfa7de44d, --template option is ignored if --style is specified,
which is wrong according to the doc of show_changeset():
Display format will be the first non-empty hit of:
1. option 'template'
2. option 'style'
...
Make hgweb.refresh() also look at phaseroots file (in addition to 00changelog.i
file) and reload the repo when os.stat returns different mtime or size than
cached, signifying the file was modified.
This way if user changes phase of a changeset (secret <-> draft), there's no
need to restart hg serve to see the change.
d735f8a82023 is nice for test output, but it also affects command-server
channel. Command-server client shouldn't receive echo-back message, which
makes it harder to parse the output.
Used to be that `hg help hgrc.paths` would show
"paths"
-------
Assigns symbolic names to repositories. The left side is the symbolic
name, and the right gives the directory or URL that is the location of the
repository. Default paths can be declared by setting the following
entries.
and stop there. Obviously the result seems better as shown in the
attached test.
This is a complete rewrite of the default template to use labels. This
seems ultimately useless to me in most cases. The biggest benefit of
this patch to me seems to be a fairly complicated example of the
templating engine. It was a lot of hard work to figure out the precise
acceptable syntax, since it's almost undocumented. Hat tip to Steve
Losh's smartlog template, which helped me figure out a lot of the
syntax. Hopefully later I can use the present default log template
as an example for documenting the templating engine.
A test is attached. My goal was to match the --color=debug output,
which may differ slightly in newlines from the actual ANSI escape
codes output. I consider this an acceptable invisible deviation.
There seems to be a considerable slowdown with this rewrite.
Before:
$ time hg log -T default -r .~100::. > /dev/null
real 0m0.882s
user 0m0.812s
sys 0m0.064s
$ time hg log -T default -r .~100::. > /dev/null
real 0m0.872s
user 0m0.796s
sys 0m0.068s
$ time hg log -T default -r .~100::. > /dev/null
real 0m0.917s
user 0m0.836s
sys 0m0.076s
After:
$ time hg log -T default -r .~100::. > /dev/null
real 0m1.480s
user 0m1.392s
sys 0m0.072s
$ time hg log -T default -r .~100::. > /dev/null
real 0m1.500s
user 0m1.400s
sys 0m0.088s
$ time hg log -T default -r .~100::. > /dev/null
real 0m1.462s
user 0m1.364s
sys 0m0.092s
Following the maxim, "make it work, profile, make it faster, in that
order", I deem this slowdown acceptable for now.
I suspect but have not confirmed that a big slowdown comes from
calling keywords twice in the file templates, once to test the
existence of output and again to actually list the output. If so, a
simple speedup might be to improve the templating engine to cache
keywords when called more than once on the same revision.
TODO: I found a bug while working on this. The following stack traces:
hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'
When 62900f2373fa introduced phases to the `hg log --debug` output, it
also disabled outputting public phase. At the same time, it always
shows phases in the default template, `hg log --debug -T default`.
Those two should produce the same output, but they don't.
I think it makes a lot more sense to always show all phases. There's
already loss of backwards compatibility in this case when using a
newer hg on an old hg repo, since draft commits will show up in the
output of `hg log --debug`.
Finally, I just don't think that any sort of information should be
hidden with --debug. This flag should be about showing as much
information as possible.
Akin to b5baef1e39f6 which did this for `hg log`, the following sets
the correct phase for the {phase} keyword when the context is a parent
of the current cset. This allows templates such as the following to be
defined,
parent = '{label("log.parent changeset.{phase}",
"parent: {rev}:{node|formatnode}")}\n'
which when called on a parent (e.g. with the `parents` template
keyword), will produce the correct phase.
This is most noticeable when using custom templates. Before this
patch, a template like {label("foo.bar", baz)} would emit
[foo.bar|]
whenever baz was empty. This cset simply omits all output when baz is
empty.
Traditionally, the way to specify a command for hgweb was to use url query
arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
error (e.g. "400 no such method: badcmd").
But there's also another way to specify a command: as a url path fragment (e.g.
"/graph"). Before, hgweb was made forgiving (looks like it was made in
cd356f4efd91) and user could put any unknown command in the url. If hgweb
couldn't understand it, it would just silently fall back to the default
command, which depends on the actual style (e.g. for paper it's shortlog, for
monoblue it's summary). This was inconsistent and was breaking some tools that
rely on http status codes (as noted in the issue4071). So this patch changes
that behavior to the more consistent one, i.e. hgweb will now return "400 no
such method: badcmd".
So if some tool was relying on having an invalid command return http status
code 200 and also have some information, then it will stop working. That is, if
somebody typed foobar when they really meant shortlog (and the user was lucky
enough to choose a style where the default command is shortlog too), that fact
will now be revealed.
Code-wise, the changed if block is only relevant when there's no "?cmd" query
parameter (i.e. only when command is specified as a url path fragment), and
looks like the removed else branch was there only for falling back to default
command. With that removed, the rest of the code works as expected: it looks at
the command, and if it's not known, raises a proper ErrorResponse exception
with an appropriate message.
Evidently, there were no tests that required the old behavior. But, frankly, I
don't know any way to tell if anyone actually exploited such forgiving behavior
in some in-house tool.
Changeset 1440ec8e33c0 switched the order of the operand of the "&" computation
to work around an issue from repo-wide spanset. The need for a workaround has been
alleviated by the introduction of `fullreposet`. So we restore it to normal.
The benchmark shows no significant changes as expected.
We also revert the bogus test change introduced by 1440ec8e33c0. The order is
actually important.
Before this patch, "hg qselect" with --pop/--reapply may pop patches
unexpectedly, even when all of patches applied before "qselect" are
still pushable.
Strictly speaking about the condition of this issue:
- before "qselect"
- there are N applied patches
- the index of the guarded patch X in the series is less than N
- after "qselect"
- X is still guarded, and
- all of applied patched are still pushable
In the case above, "hg qselect" should keep current status, but it
actually tries to pop patches because of X.
The index in "the series" should be used to examine "pushable" of a
patch by "mq.pushablek()", but the index in "applied patches" is used,
and this may cause unexpected examination of guarded patch.
To examine "pushable" of already applied patch correctly, this patch
uses "mq.applied[i].name": "pushable" is the function introduced by
the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".
Before this patch, "hg qselect" with --pop/--reapply may pop incorrect
patches, because the index in "applied patches" is used to pop patches
by "mq.pop()", even though the index in "the series" should be used.
For example, when the already applied patch becomes guarded and it
follows the already guarded (= not yet applied) one, "hg qselect" is
aborted, because it tries to pop to guarded one.
This patch uses "mq.applied[i - 1].name" to pop to the patch, of which
the index in the "applied ones" is "i - 1".
Before this patch, "hg qselect --reapply" is aborted when "--verbose"
is specified, because "mq.appliedname()" returns "INDEX PATCHNAME"
instead of "PATCHNAME" in such case and "mq.push" can't accept the
former as the name of patch.
This patch uses "mq.applied[i].name" instead of "mq.appliedname(i)" as
the name of the patch to be pushed for safety.
Now, there is no code path using "mq.appliedname()", and it should be
removed to prevent developers from using it in the wrong way like this
issue.
Before this patch, "hg qselect" may report incorrect numbers for
"number of guarded, applied patches has changed", because it examines
"pushable" of patches by the index not in "the series" but in "applied
patches", even though "mq.pushable()" expects the former.
To report correct numbers for changing "number of guarded, applied
patches", this patch uses the name of applied patch to examine
pushable-ness of it.
This patch also changes the result of existing "hg qselect" tests,
because they doesn't change pushable-ness of already applied patches.
This patch assumes that "hg qselect" focuses on changing pushable-ness
only of already applied patches, because:
- the report message uses not "previous" (in the series) but
"applied"
- the logic to pop patches for --pop/--reapply examines
pushable-ness only of already applied ones (in fact, there are
some incorrect code paths)
Before this patch, the shell alias causes failure when it takes its
specific (= unknown for "hg") options in the command line, because
"_parse()" can't accept them.
This is the regression introduced by 7849ac1dbc57.
It fixed the issue that ambiguity between shell aliases and commands
defined by extensions was ignored. But it also caused that ambiguous
shell alias is handled in "_parse()" even if it takes specific options
in the command line.
To avoid such failure, this patch checks shell alias again after
loading extensions.
All aliases and commands (including ones defined by extensions) are
completely defined before the 2nd (= newly added in this patch)
"_checkshellalias()" invocation, and "cmdutil.findcmd(strict=False)"
can detect ambiguity between them correctly.
For efficiency, this patch does:
- omit the 2nd "_checkshellalias()" invocation if "[ui] strict= True"
it causes "cmdutil.findcmd(strict=True)", of which result should
be equal to one of the 1st invocation before adding aliases
- avoid removing the 1st "_checkshellalias()" invocation
it causes "cmdutil.findcmd(strict=True)" invocation preventing
shell alias execution from loading extensions uselessly
Use the existing method cmdutil.bailifchanged() instead of
implementing it again in fetch.py. An effect of this is that the error
messages in case of uncommited changes will be different.
Bid merge is now the default and it is not necessary to tell the user that an
experimental feature kicked in.
(It could however still be relevant to get a notice that it is one of the rare
criss-cross merge situations so the user is warned that the situation is more
tricky than usual.)
In most cases merges will work exactly as before.
The only difference is in criss-cross merge situations where there is multiple
ancestors. Instead of picking an more or less arbitrary ancestor, it will
consider both ancestors and pick the best bids.
Bid merge can be disabled with --config merge.preferancestor='!'.
Before this patch, no message is shown for failure of merging at "hg
import".
In such case, merging patch is imported as a normal revision silently,
and it may confuse users.
For simplicity, this patch recommends just using "--exact", even
though importing the merging patch itself is possible without it if:
- the hash of the 1st parent in the patch is equal to one of the
patch imported just before (or the parent of the working
directory, for the 1st patch of the series), and
- the hash of the 2nd parent in the patch is known in the local
repository
When grafting something with a matching origin, it would normally be skipped:
skipping already grafted revision 123 (23 also has origin 12)
But after stripping a graft origin, graft could fail with a reference to the
origin that no longer exists:
abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'!
Instead, detect that the origin is unknown and skip it anyway, like:
skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)
Pull would send a getbundle command where common heads were sent both as common
and head, even though there is no reason to request a common head.
The request was thus twice as big as necessary and more likely to hit HTTP
header size limits.
Instead, don't request heads that already are common.
This is fixed in bundlerepo.getremotechanges . It could perhaps also have been
fixed in discovery.findcommonincoming but that would have a bigger impact.
The value '*' currently designates that bid merge should be used. The best
way to test bid merge is to set preferancestor=* in the configuration file ...
but then it would abort with unknown revision '*' when other code paths ended
up in changectx.ancestor .
Instead, just skip and ignore the value '*' when looking for a preferred
ancestor.
Updates with uncommited changes will always only have one ancestor - the parent
revision. Updates between existing revision should (and will) always give the
same result no matter which ancestor is used. The warning is thus only relevant
when doing a "real" merge.
This makes hg log --follow --patch work, since in cmdutil._makelogrevset we
use the non-follow matcher for hg log --follow --patch with no file arguments.
This has actually been broken since at least Mercurial 2.8 -- hg log --patch
with largefiles only used to work when no largefiles existed. Rev 658ce4a0a0a9
exposed this bug for all cases.
When the authorship of the changeset folded in does not match that of
the base changeset, we currently use the configured ui.username
instead. This is especially surprising when the user is not the author
of either of the changesets. In such cases, the resulting authorship
(the user's) is clearly incorrect. Even when the user is folding in a
patch they authored themselves, it's not clear whether they should
take over the authorship. Let's instead keep it simple and always
preserve the base changeset's authorship. This is also how
"git rebase -i" handles folding/squashing.
This behavior didn't make much sense and interacts badly with things
that use unbundle internally like shelve. Presumably, the original
rationale was that since bundles didn't contain bookmarks, this gave a
sense of keeping bookmarks up-to-date like would happen with a
corresponding pull. However, since it only updated the current active
bookmark, and bare update already did that anyway, this is pretty
slim.
Notably, the corresponding test actually works better without this
feature.
By the magic of code movement, we ended up dropping unknown and ignored
information when comparing the working directory with a non-parent revision.
Let's stop doing it and add a test.
Old behavior:
hg help x hg x -h hg help -e x hg help -c x
config topic topic (!) - cmd
showconfig cmd topic (!) - cmd
rebase cmd cmd ext cmd
New behavior:
hg help x hg x -h hg help -e x hg help -c x
config topic cmd - cmd
showconfig cmd cmd - cmd
rebase cmd cmd ext cmd
This patch changes help text for "--edit" option of commands below:
- fetch
- qnew
- qrefresh
- qfold
- commit
- tag
This unification reduces translation cost, too.
This patch chooses not "further edit commit message already specified"
(of "hg commit") but "invoke editor on commit messages" as unified
help text for "--edit" option, because the latter is much older than
the former.
We used to have --style nosuch to list templates, but --style is now
merged with --template/-T where random strings are acceptable
templates. So we reserve 'list' to allow listing templates.
In Mercurial 3.0, "hg status" can list the same file twice if it was removed
but still exists in working directory, i.e. removed by "hg forget":
$ hg status --rev 0 removed
R removed
? removed
But since 64d05ea3a10f, untracked state, "?", is no longer displayed in this
example.
I think the new behavior is correct since a file should have single state, but
if it is a bug, this patch should be dropped.
When a bundle2 parts generator returns a non callable value, it should not be
used as a reply handler. The changegroup part generator is already having this
case of behavior when there is no changegroup to push. This changeset prevent a
crash for user of the experimentable bundle2 feature.
With this change resolve and revert produce consistent output when run with no
arguments:
$ hg resolve
abort: no files or directories specified
(use --all to remerge all files)
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
Before this patch, largefiles gotten from revisions other than the
parent of the working directory at "hg revert" become "clean"
unexpectedly in steps below:
1. "repo.status()" is invoked (for status check before reverting)
1-1 "dirstate" entry for standinfile SF is "normal"-ed
(1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed)
2. "cmdutil.revert()" is invoked
2-1 standinfile SF is updated in the working directory
2-2 "dirstate" entry for SF is NOT updated
3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()")
3-1 largefile LF (for SF) is updated in the working directory
3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2)
3-3 "lfdirstate" entry for LF is "normal"-ed
3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file (by 3-3)
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 3-3 and 3-4) as "clean".
When largefiles are reverted, they should be "normallookup"-ed
forcibly.
This patch uses "normallookup" on "lfdirstate" while reverting, by
passing "True" to newly added argument "normallookup".
Forcible "normallookup"-ing is not so expensive, because list of
target largefiles is explicitly specified in this case.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)
Before this patch, largefiles gotten from "other" revision (with
conflict) at "hg merge" become "clean" unexpectedly in steps below:
1. "repo.status()" is invoked (for status check before merging)
1-1 "dirstate" entry for standinfile SF is "normal"-ed
1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed
2. "merge.update()" is invoked
2-1 SF is updated in the working directory
(ASSUMPTION: user choice "other" at conflict)
2-2 "dirstate" entry for SF is "merge"-ed
3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
3-1 largefile LF (for SF) is updated in the working directory
3-2 "dirstate" returns "m" for SF (by 2-2)
3-3 "lfdirstate" entry for LF is left as it is
3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file (by 1-2)
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 1-2 and 3-4) as "clean".
When state of standinfile in "dirstate" is "m", largefile should be
"normallookup"-ed.
This patch invokes "normallookup" on "lfdirstate" for merged files.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 3-4)
Before this patch, largefiles gotten from "other" revision (without
conflict) at "hg merge" become "clean" unexpectedly in steps below:
1. "merge.update()" is invoked
1-1 standinfile SF is updated in the working directory
1-2 "dirstate" entry for SF is "normallookup"-ed
2. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
2-1 largefile LF (for SF) is updated in the working directory
2-2 "dirstate" returns "n" for SF (by 1-2)
2-3 "lfdirstate" entry for LF is "normal"-ed
2-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
timestamp of LF is stored into "lfdirstate" file
(ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 2-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 2-3 and 2-4) as "clean".
When timestamp is not set (= negative value) for standinfile in
"dirstate", largefile should be "normallookup"-ed regardless of
rebasing or not, because "n" state in "dirstate" doesn't ensure
"clean"-ness of a standinfile at that time.
This patch uses "normallookup" instead of "normal", if "mtime" of
standin is unset
This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, "lfdirstate" should
be updated with "dirstate" simultaneously while "merge.update"
execution: maybe by hooking "recordupdates"
It is also why this patch (temporarily) uses internal field "_map" of
"dirstate" directly.
This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 2-4)
This patch newly adds "test-largefiles-update.t", to avoid increasing
cost to run other tests for largefiles by subsequent patches
(especially, "[debug] dirstate.delaywrite" causes so).
This previously died in _revdescendants() taking the min() of the first set to
only(), when it was empty. An empty second set already worked. Likewise,
descendants() already handled an empty set.
This patch makes commit message shown in text editor customizable by
template. For example, this can advertise:
- sample commit messages for routine works,
- points to call attention before commit,
- message of the day, and so on
To show commit message correctly even in problematic encoding, this
patch chooses the latter below:
- replace "buildcommittext" with "buildcommittemplate" completely
- invoke "buildcommittemplate" only if '[committemplate] changeset'
is configured explicitly
For example, if multibyte character ending with backslash (0x5c) is
followed by ASCII character 'n' in the customized template, sequence
of backslash and 'n' is treated as line-feed unexpectedly (and
multibyte character is broken, too).
This corruption occurs in 'decode("string-escape")' while parsing
template string.
Add a new internal:tagmerge merge tool which implements an automatic merge
algorithm for mercurial's tag files
The tagmerge algorithm is able to resolve most merge conflicts that
currently would trigger a .hgtags merge conflict. The only case that
it does not (and cannot) handle is that in which two tags point to
different revisions on each merge parent _and_ their corresponding tag
histories have the same rank (i.e. the same length). In all other
cases the merge algorithm will choose the revision belonging to the
parent with the highest ranked tag history. The merged tag history is
the combination of both tag histories (special care is taken to try to
combine common tag histories where possible).
The algorithm also handles cases in which tags have been manually
removed from the .hgtags file and other similar corner cases.
In addition to actually merging the tags from two parents, taking into
account the base, the algorithm also tries to minimize the difference
between the merged tag file and the first parent's tag file (i.e. it
tries to make the merged tag order as as similar as possible to the
first parent's tag file order).
The algorithm works as follows:
1. read the tags from p1, p2 and the base
- when reading the p1 tags, also get the line numbers associated to each
tag node (these will be used to sort the merged tags in a way that
minimizes the diff to p1). Ignore the file numbers when reading p2 and
the base
2. recover the "lost tags" (i.e. those that are found in the base but not on p1
or p2) and add them back to p1 and/or p2
- at this point the only tags that are on p1 but not on p2 are those new
tags that were introduced in p1. Same thing for the tags that are on p2
but not on p2
3. take all tags that are only on p1 or only on p2 (but not on the base)
- Note that these are the tags that were introduced between base and p1 and
between base and p2, possibly on separate clones
4. for each tag found both on p1 and p2 perform the following merge algorithm:
- the tags conflict if their tag "histories" have the same "rank" (i.e.
length) _AND_ the last (current) tag is _NOT_ the same
- for non conflicting tags:
- choose which are the high and the low ranking nodes
- the high ranking list of nodes is the one that is longer.
In case of draw favor p1
- the merged node list is made of 3 parts:
- first the nodes that are common to the beginning of both the
low and the high ranking nodes
- second the non common low ranking nodes
- finally the non common high ranking nodes (with the last one
being the merged tag node)
- note that this is equivalent to putting the whole low ranking node
list first, followed by the non common high ranking nodes
- note that during the merge we keep the "node line numbers", which will
be used when writing the merged tags to the tag file
5. write the merged tags taking into account to their positions in the first
parent (i.e. try to keep the relative ordering of the nodes that come
from p1). This minimizes the diff between the merged and the p1 tag files
This is done by using the following algorithm
- group the nodes for a given tag that must be written next to each other
- A: nodes that come from consecutive lines on p1
- B: nodes that come from p2 (i.e. whose associated line number is None)
and are next to one of the a nodes in A
- each group is associated with a line number coming from p1
- generate a "tag block" for each of the groups
- a tag block is a set of consecutive "node tag" lines belonging to the
same tag and which will be written next to each other on the merged
tags file
- sort the "tag blocks" according to their associated number line
- put blocks whose nodes come all from p2 first
- write the tag blocks in the sorted order
Notes:
- A few tests have been added to test-tag.t. These tests are very specific to
the new internal:tagmerge tool, so perhaps they should be moved to their own
test file.
- The merge algorithm was discussed in a thread on the mercurial mailing list.
In http://markmail.org/message/anqaxldup4tmgyrx a slightly different algorithm
was suggested. In it the p1 and p2 tags would have been interleaved instead of
put one before the other. It would be possible to implement that but my tests
suggest that the merge result would be more confusing and harder to understand.
As extensively detailed by Pierre-Yves[1], simplemerge's minimal
markers can result in hopeless confusion for many common merges. As it
happens, we accidentally inherited this behavior when we borrowed
simplemerge from bzr; it is not the behavior used by RCS's merge(1),
Since merge(1) (and not bzr) is what we aim to emulate when emulating
RCS's merge markers, we simply turn this feature off. This brings us
in line with the behavior of CVS, SVN, and Git as a bonus.
(NB: using conflict markers with Mercurial is discouraged.)
[1] http://markmail.org/message/wj5mh3lc46czlvld
convert glob tessa
We are going to introduce a setting to control the "minimisation" feature of
``internal:merge``. So we need more interesting conflicting content. We change
the content in an independent changeset to make sure the coming code change
leave the output unchanged.
Before this patch, 'detailed' is used as the default of '[ui]
mergemarkers'. This embeds non-ASCII characters in tags, branches,
bookmarks, author and/or commit descriptions into merged files in the
encoding specified by '--encoding' global option, 'HGENCODING' or
other locale setting environment variables.
But, if files to be merged use another encoding, this behavior breaks
consistency of encoding in merged files.
For example, ISO-2022-JP or EUC-JP are sometimes used as the file
encoding for Japanese characters, because of historical and/or
environmental reasons, even though UTF-8 or Shift-JIS are ordinarily
used as the terminal encoding.
This can't be resolved automatically, because Mercurial doesn't aware
encoding of managed files.
This patch uses 'basic' as the default of '[ui] mergemarkers' to avoid
embedding encoding sensitive characters for safety.
This patch puts '[ui] mergemarkers = detailed' into default hgrc file
for tests, to reduce changes for tests in this patch.
Previously, the directory '.hg/largefiles' would always be created if it didn't
exist when the lfdirstate was opened. If there were no standin files, no
dirstate file would be created in the directory. The end result was that
enabling the largefiles extension globally, but not explicitly adding a
largefile would result in the repository eventually sprouting this directory.
Creation of this directory effectively changes readonly operations like summary
and status into operations that require write access. Without write access,
commands that would succeed without the extension loaded would abort with a
surprising error when the extension is loaded, but not actively used:
$ hg sum -R /tmp/thg --config extensions.largefiles=
parent: 16541:00dc703d5aed
repowidget: specify incoming bundle by plain file path to avoid url parsing
branch: default
abort: Permission denied: '/tmp/thg/.hg/largefiles'
This change is simpler than changing the callers of openlfdirstate() to use the
'create' parameter that was introduced in 74522122b97d, and probably how that
should have been implemented in the first place.
Previously there was no way of telling how much children or bookmarks or tags a
certain changeset has in a template. It was possible to tell if a changeset has
either 0 or not 0 bookmarks, but not to tell if it has 1 or 2 of them, for
example.
This filter, simply named count, makes it possible to count the number of items
in a list or the length of a string (or, anything that python's len can count).
E.g.: {children|count}, {bookmarks|count}, {file_adds|count}.
Testing the filter on node hash and shortened node hash is chosen because they
both have defined length.
As for lists of strings - children, tags and file_adds are used, because they
provide some variety and also prove that what's counted is the number of string
items in the list, and not the list stringified (they are lists of non-empty,
multi-character strings).
Additionally, revset template function is used for testing the filter, since
the combination is very flexible and will possibly be used together a lot.
(The previous version of this patch had an incorrect email subject and was
apparently lost - patchwork says the patch has been accepted, but it's not so.
The changes between that and this patch are minimal: now the filter does not
disturb the alphabetical order of function definitions and dict keys.)
We do all the things in one go now, updating existing bookmark, adding new ones,
and overwriting the ones explicitly specified for --bookmark. This impacts the
tests by removing some duplicated or unnecessary output.
The discovery phases for bookmarks now use the list of explicitly pushed bookmarks
to do addition, removal and overwriting.
Tests are impacted because this reduces the amount of listkeys calls issued, removes
some duplicated messages and improves the accuracy of some messages.
We need to explicitly push all local bookmarks when doing the clone from a local
repo to a remote one through ssh. This will let us remove the manual export of
bookmarks in clone and rely on the official exchange in push and pull instead.
There is no reason for bookmarks to get a special treatment. As a first step we
move the code as is in the `exchange.pull` function. Integration with the rest
of the flow will come later.
Adding bookmarks to pull means that most clone paths are now pulling bookmarks
through pull. We ensure that bookmark-update messages are properly suppressed in
that case.
In test-pull-http.t the 'requesting all changes' message disappear because we
now get the authentication error on the `listkeys`command before such message
is printed.
Pulling bookmarks is done in two rounds. First we do a simple update, then we use
the content of the `bookmark` argument to possibly overwrite some bookmark
with their remote location.
The second step was not done right after the first one for some obscure reason.
We now perform them one after the other.
These files were previously not backed up because the backup mechanism was not
smart enough. This leads to data lose for the user since uncommitted contents
were discarded.
We now properly move the modified version to <filename>.orig before deleting it.
We have to use a small hack to do a different action if "--no-backup" is
specified. This is needed because the backup process is actually a move (not a
copy) so the file is already missing when we backup. The internet kitten is a
bit disapointed about that, but such is life.
This patch concludes the "lets refactor revert" phases. We can now open the
"Lets find stupid bug with renames and merge" phases.
I'm sure that now that the code is clearer we could do it in another simpler
way, but I consider the current improvement good enough for now.
The tests often set ui.interactive to control normally interactive prompts from
stdin. That gave an output where it was non-obvious what prompts got which
which response, and the output lacked the newline users would see after input.
Instead, if the input not is a tty, write the selection and a newline.
This will give PKI-secure behaviour out of the box, without any configuration.
Setting web.cacerts to any value or empty will disable this trick.
This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which
didn't have certificate validation at all.
Though we have to duplicate import statements, .t test is still more handy
than .py test which has cryptic .out file.
This change allows to skip a part of test by #if conditional, which my next
patch series depends on.
This prepares for porting test-commandserver.py to .t test.
Though command-server test needs many Python codes, .t test will be more
readable than .py test thanks to inlined output.
In order to mimic module-level evaluation, globals and locals should be the
same object, so doctest does not pass separate locals dict.
https://docs.python.org/2.7/reference/simple_stmts.html#exec
This fixes NameError in the following example:
>>> import foo
>>> def bar():
... foo # must exist in globalvars
Since both 'bar' and 'bar-copied' matched 'bar-copied2', Git's copy detection
would sometimes result in 'bar' being the source for 'bar-copied2' and
sometimes 'bar-copied'. Change bar in a separate commit so that that would no
longer be the case.
Parent will now always be updated or added when qrefreshing HG patches. Plain
patches will not be changed, but patches that neither are plain nor HG will be
upgraded to HG patches on first refresh.
There would in some cases be an empty line between headers and the description -
that does not seem right.
There should also be an empty line between description and diff - but that was
missing.
These two mistakes would sometimes make it up for each other so we fix both at
once to just show the improvement.
Instead of writing an extra newline when writing a header line, write an extra
line when it not is written as a part of the description but is necessary
anyway.
This default mirrors the default for 'git diff'. Other commands have slightly
different defaults -- for example, the move/copy detection for 'git blame'
assumes that a hunk is moved if more than 40 alphanumeric characters are the
same, or copied if more than 20 alphanumeric characters are the same. 50% seems
to be the most common default, though.
This patch adds up a 'cuser' and 'csys'(cputime) info in report.json file
which generated when --json is enabled while testing.
Now the new format of report.json file is as below.
testreport ={
"test-success.t": {
"csys": "1.041",
"cuser": "1.041",
"result": "success",
"time": "2.041"
}
"test-failure.t": {
"csys": "1.041",
"cuser": "1.041",
"result": "failure",
"time": "4.430"
}
"test-skip.t": {
"csys": "1.041",
"cuser": "1.041",
"result": "skip",
"time": "3.754"
}
}
If the selected formatter is other than plainformatter, raw data are passed
to the formatter. In this case, it isn't necessary (and not possible) to
calculate column widths.
Field names are substituted to be the same as "log" command.
There are a few limitations:
- "binary file" message is not included in formatted output.
- no data structure for multiple files. all lines are packed to single list.
Git is fairly unique among VCSes in that it doesn't record copies and renames,
instead choosing to detect them on the fly. Since Mercurial expects copies and
renames to be recorded, it can be valuable to preserve this history while
converting a Git repository to Mercurial. This patch adds a new convert option,
called 'convert.git.similarity', which determines how similar files must be to
be treated as renames or copies.
Before, the format was
label(labeled text) # single label
[label1 label2](labeled text) # multiple
Now, it's
[labels|labeled text]
..which should make things a bit more clear.
This is a debug option for showing labels. This can be helpful for
knowing which labels are available for colouring or to see the output
when defining your own templates. A couple of tests are included.
The following patch splits up changed lines along tabs (using
re.findall), and gives them a "diff.tab" label. This can be used by
the color extension for colorising tabs, like it does right now with
trailing whitespace.
I also provide corresponding tests.
Strip executes a revset like this:
max(parents(_intlist('1234\x001235')) - _intlist('1234\x001235'))
Previously the parents() revset would do 'subset & parents' which iterates over
each item in the subset and checks if it's in parents. subset is usually the
entire repo (a spanset) so this takes a while.
Reversing the parameters to be 'parents & subset' means the operation becomes
O(number of parents) instead of O(size of repo). It also means the result gets
evaluated immediately (since parents isn't a lazy set), but I think this is a
win in most scenarios.
This shaves 0.3 seconds off strip (amend/histedit/rebase/etc) for large repositories.
revset #0: parents(20000)
0) obsolete feature not enabled but 54243 markers found!
! wall 0.006256 comb 0.010000 user 0.010000 sys 0.000000 (best of 289)
1) obsolete feature not enabled but 54243 markers found!
! wall 0.000391 comb 0.000000 user 0.000000 sys 0.000000 (best of 4323)
"diff" allows to embed changes in the target revision into template
output, even if the command itself doesn't take "--patch" option
Combination of "[committemplate]" configuration and "diff" template
function can achieve the feature like issue231 ("option to have diff
displayed in commit editor buffer")
http://bz.selenic.com/show_bug.cgi?id=231
For example, templating below can be used to add each "diff" output
lines "HG: " prefix::
{splitlines(diff) % 'HG: {line}\n'}
This patch implements "diff" not as "a template keyword" but as "a
template function" to take include/exclude patterns at runtime.
It allows to specify target files of command (by -I/-X command line
options) and "diff" separately.
This produces slightly bad results when branches are in play, but
overall I think it's probably worthwhile. We might be able to do
better with branches somehow, but I haven't given it any thought.
Adds a test that checks if the working copy parent and the working copy are in a
good state if an exception happens between the time the working copy parent is
set and the time the actual updates are recorded in the dirstate.
This patch added a new functionality '--json'. While testing, if '--json'
is enabled then test result data gets stored in newly created "report.json"
file in the following format.
testreport ={
"test-success.t": {
"result": "success",
"time": "2.041"
}
"test-failure.t": {
"result": "failure",
"time": "4.430"
}
"test-skip.t": {
"result": "skip"
"time": "3.754"
}
}
Otherwise, if '--json' is enabled but json module was not installed then it
will raise an error "json module not installed".
This "report.json" file will further accessed by html/javascript file for
graph usage.
Functions like getbundle and classes like unbundle10 really manipulate
changegroups and not bundles. A HG10 bundle is the same as a changegroup
plus a small header, but this is no longer the case for a HG2X bundle,
so it's better to separate the names a bit.
A common mistake can be to type 'hg rebase -i' to discover interactive history
editing. We add a -i/--interactive flag as discussed in the sprint and deprecate
it right away, but hint people using it to use histedit instead.
Some users clone from a server before ever running 'hg config --edit',
so they don't see our helpful template for things like enabling the
username. Attempt to give them some helpful guidance.
A future patch is going to add some extra commented-out boilerplate to
the top of .hg/hgrc during clone. In order to make this test not
require regular updates, switch to searching for [hooks] or [acl] and
print file from the first match to that pattern.
I was wondering if revisions in the initial set that are still ancestors of other
elements in the initial set were yielded by `changelog.ancestors`. I now have my
answer (they do) and Mercurial has a new test.
We should only exchange obsolete markers related to the changesets
that are being exchanged. For example, if `A'` is a successor of `A`,
we do not want to push the marker if we are not exchanging
`A'`. Otherwise `A` would disappear without a successor, leading to confusion
for both users and the evolution mechanism.
Therefore we now exchange only the markers relevant to the subset of nodes
involved in the push (the nodes themselves may be already common but were
selected by --rev (or the lack of --rev)).
Note that all selected markers are still exchanged on each push. We do
not have a discovery protocol for markers in core yet. Such discovery
would save us the exchange of markers known on both side.
The set of relevant markers is currently unordered. Therefore the
markers will be added in arbitrary order. We sort the list of markers
beforehand to ensure stable output for testing.
We are going to only exchange markers relevant to the exchanged
changesets. So we need to change this marker to use a known changeset as
a successor instead of a precursor.
To introduce a bundle2 way to exchange obsolescence markers, we need to
have some information available to exchange. Introduce markers relevant
to changesets involved in the exchange. The new markers reference the
changesets as successor nodes of clowny (nonexistent) hashes so that
other than being exchanged they have no effect.
We introduce them in two waves as push is expected to be smart about the
number of markers it exchanges sooner than pull.
Before this patch, predicates defined in "[revsetalias]" can't be used
in the query specified to template function "revset()", because:
- "revset()" uses "localrepository.revs()" to get query result, but
- "localrepository.revs()" passes "None" as "ui" to "revset.match()", then
- "revset.match()" can't recognize any alias predicates
To enable alias predicates to be used in "revset()" function, this
patch invokes "revset.match()" directly with "repo.ui".
This patch doesn't make "localrepository.revs()" pass "self.ui" to
"revset.match()", because this may be intentional implementation to
prevent alias predicates from shadowing built-in ones and breaking
functions internally using "localrepository.revs()".
Even if it isn't intentional one, the check for shadowing should be
implemented (maybe on default branch) before fixing it for safety.
Convert will normally only process files that were changed in a source
revision, apply the filemap, and record it has a change in the target
repository. (If it ends up not really changing anything, nothing changes.)
That means that _if_ the filemap is changed before continuing an incremental
convert, the change will only kick in when the files it affects are modified in
a source revision and thus processed.
With --full, convert will make a full conversion every time and process
all files in the source repo and remove target repo files that shouldn't be
there. Filemap changes will thus kick in on the first converted revision, no
matter what is changed.
This flag should in most cases not make any difference but will make convert
significantly slower.
Other names has been considered for this feature, such as "resync", "sync",
"checkunmodified", "all" or "allfiles", but I found that they were less obvious
and required more explanation than "full" and were harder to describe
consistently.
Before this patch, largefiles in the working directory aren't updated
correctly, if transplant is aborted by conflict. This prevents users
from viewing appropriate largefiles while resolving conflicts.
While transplant, largefiles in the working directory are updated only
at successful committing in the special code path of
"lfilesrepo.commit()".
To update largefiles even if transplant is aborted by conflict, this
patch wraps "scmutil.marktouched", which is invoked from "patch.patch"
with "files" list of added/modified/deleted files.
This patch invokes "updatelfiles" with:
- "printmessage=False", to suppress "getting changed largefiles ..."
messages while automated committing by transplant
- "normallookup=True", because "patch.patch" doesn't update dirstate
for modified files
in such case, "normallookup=False" may cause marking modified
largefiles as "clean" unexpectedly
Before this patch, largefiles in the working directory aren't updated
correctly, if rebase is aborted by conflict. This prevents users from
viewing appropriate largefiles while resolving conflicts.
While rebase, largefiles in the working directory are updated only at
successful committing in the special code path of
"lfilesrepo.commit()".
To update largefiles even if rebase is aborted by conflict, this patch
centralizes the logic of updating largefiles in the working directory
into the "mergeupdate" wrapping "merge.update".
This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, largefiles in the
working directory should be updated with other (normal) files
simultaneously while "merge.update" execution: maybe by hooking
"applyupdates".
"Action list based updating" introduced by hooking "applyupdates" will
also improve performance of updating, because it automatically
decreases target files to be checked.
Just after this patch, there are some improper things in "Case 0" code
path of "lfilesrepo.commit()":
- "updatelfiles" invocation is redundant for rebase
- detailed comment doesn't meet to rebase behavior
These will be resolved after the subsequent patch for transplant,
because this code path is shared with transplant.
Even though replacing "merge.update" in rebase extension by "hg.merge"
can also avoid this problem, this patch chooses centralizing the logic
into "mergeupdate", because:
- "merge.update" invocation in rebase extension can't be directly
replaced by "hg.merge", because:
- rebase requires some extra arguments, which "hg.merge" doesn't
take (e.g. "ancestor")
- rebase doesn't require statistics information forcibly displayed
in "hg.merge"
- introducing "mergeupdate" can resolve also problem of some other
code paths directly using "merge.update"
largefiles in the working directory aren't updated regardless of
the result of commands below, before this patch:
- backout (for revisions other than the parent revision of the
working directory without "--merge")
- graft
- histedit (for revisions other than the parent of the working
directory
When "partial" is specified, "merge.update" doesn't update dirstate
entries for standins, even though standins themselves are updated.
In this case, "normallookup" should be used to mark largefiles as
"possibly dirty" forcibly, because applying "normal" on lfdirstate
treats them as "clean" unexpectedly.
This is reason why "normallookup=partial" is specified for
"lfcommands.updatelfiles".
This patch doesn't test "hg rebase --continue", because it doesn't
work correctly if largefiles in the working directory are modified
manually while resolving conflicts. This will be fixed in the next
step of refactoring for largefiles.
All changes of tests/*.t files other than test-largefiles-update.t in
this patch come from invoking "updatelfiles" not after but before
statistics output of "hg.update", "hg.clean" and "hg.merge".
Code paths below expect "hg.updaterepo" (or "hg.update" using it) to
execute linear merging:
- "update" in commands
- "postincoming" in commands, used for:
- "hg pull --update"
- "hg unbundle --update"
- "hgsubrepo.get" in subrepo
For linear merging with largefiles, standins should be updated
according to (possibly dirty) largefiles before "merge.update"
invocation to detect conflicts correctly.
Before this patch, only the "update" command can execute linear merging
correctly, because largefiles extension takes care of only it.
This patch moves "updatestandin" invocation from "overrideupdate" ("hg
update" wrapper) to "_hgupdaterepo" ("hg.updaterepo" wrapper) to
execute linear merging in "hg.updaterepo" correctly.
This is also a preparation to centralize the logic of updating
largefiles in the working directory into the function wrapping
"merge.update" in the subsequent patch.
Before this patch, standinds not known to the restored dirstate at
rollback still exist after rollback of the parent of the working
directory, and they become orphans unexpectedly.
This patch unlinks standins not known to the restored dirstate.
This patch saves names of standins matched against not
"repo.dirstate[f] == 'a'" but "repo.dirstate[f] != 'r'" before
rollback, because branch merging marks files newly added to
dirstate as not "a" but "n".
Such standins will also become orphan after rollback, because they are
not known to the restored dirstate.
Before this patch, standins are restored from the NEW parent of the
working directory at "hg rollback", and this causes:
- standins removed in the rollback-ed revision are restored, and
become orphan, because they are already marked as "R" in the
restored dirstate and expected to be unlinked
- standins added in the rollback-ed revision are left as they were
before rollback, because they are not included in the new parent
(this may not be so serious)
This patch replaces the "merge.update" invocation with a specific
implementation to restore standins according to restored dirstate.
This is also the preparation to centralize the logic of updating
largefiles into the function wrapping "merge.update" in the subsequent
patch.
After that patch, "merge.update" will also update largefiles in the
working directory and be redundant for restoring standins only.
Before this patch, "hg rollback" can't restore standins correclty, if:
- old parent of the working directory is rollback-ed, and
- new parent of the working directory is not branch-tip
"overriderollback" uses "merge.update" as a kind of "revert" utility
to restore only standins with "node=None", and this makes
"merge.update" choose "branch-tip" revision as the updating target
unexpectedly.
Then, "merge.update" restores standins from the branch-tip revision
regardless of the parent of the working directory after rollback and
this may cause unexpected behavior.
This patch invokes "merge.update" with "node='.'" to restore standins
from the parent revision of the working directory.
In fact, this "merge.update" invocation will be replaced in the
subsequent patch to fix another problem, but this change is usefull to
inform reason why such complicated case should be tested.
For efficiency, this patch omits restoring standins and updating
lfdirstate, if the parent of the working directory is not rollbacked.
This patch adds the test not to confirm whether restoring is skipped
or not, but to detect unexpected regression in the future: it is
difficult to distinguish between skipping and perfectly restoring.
Before this patch, external editor is invoked when imported patch has
no commit message, even if "--exact" is specified. Then, exact-ness is
broken, because empty commit message causes failure of committing.
This patch avoids editor invocation at importing with "--exact" for
exact-ness, because commit message in the patch should be kept as it
is in such case, even if it is empty.
Before this patch, "hg import" allows combination of "--exact" and
"--edit", even though editing commit message breaks exact-ness.
This patch disallows meaningless combination of "--exact" and "--edit".
Added "unexpected leading whitespace" message to parse error
when .hgrc has a line that starts with whitespace.
Helps new users unfamiliar with syntax of rc file.
We add a ``--record-parents`` flag to debugobsolete. This can be used to record
parent information in the marker when the precursors are known locally. This
will be useful to test the "relevant markers" computation.
Local clones copy/hardlink over files directly, so the branchcaches should all
be valid. There's a slight chance that a read operation would update one of the
branchcaches, but we hold a lock over the source repo so they shouldn't cause
an invalid branchcache to be copied over, just a different, valid one.
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "normal" and "merge" as ROUTE, to distinguish
merge commits from other.
This patch adds 4 test patterns to test combination of "merge"(x2) and
"--continue"(x2).
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "merge" as ROUTE, to distinguish merge commits
from other.
This patch passes bool as "ctxorbool" to "mergeeditform", because
working context has always 2 parents at this point. Dropping the
second parent of non-merging commits is executed in "concludenode".
Unlike other patches in this series (e.g. for "hg commit"), this patch
doesn't add "normal.normal"/"normal.merge" style ROUTEs, because there
is no "merge" case in "collapse" ROUTE.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
other in "hg import" without "--bypass" case.
This patch assumes "editform" variations for "hg import" below:
import.normal.normal
import.normal.merge
import.bypass.normal
import.bypass.merge
Unlike other patches in this series, this patch uses "editor.sh"
instead of "checkeditform.sh" for the name of the script to check
"HGEDITFORM", because it has to do more than checking "HGEDITFORM".
To invoke editor forcibly in "test-import-merge.t", this patch creates
the patch not having patch description as "merge.nomsg.diff".
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "amend.normal" and "amend.merge" as ROUTE of
"editform" instead of "amend", to distinguish merge commits from other
in "hg commit --amend" case.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
others in "hg commit" without "--amend" case.
This patch assumes "editform" variations for "hg commit" below:
commit.normal.normal
commit.normal.merge
commit.amend.normal
commit.amend.merge
"mergeeditform" is factored out for subsequent patches. It takes
"ctxorbool" argument, because context object can't be passed in some
cases.
The issue fixed in the previous patch was uncovered by implementing an
extension that printed additional output locally before the push command
completed. This test emulates that.
If this change is applied before the previous patch, the test will fail
on Linux, with the local output being printed before the "remote: "
lines.
If we add bookmarks to bundle2, we need a way to test the new code.
Tests are changed beforehand to highlight that inclusion of bookmarks in bundle
does not introduce any behavior changes.
The discovery of necessary bookmark updates is now done within the "discovery
phase". This opens the door to the inclusion of bookmarks in a unified bundle2
push.
hgweb detects out-of-date repository instances (using a highly
suspect mechanism that should probably be fixed) and obtains a new
repository object if needed.
This patch changes the repository object copy to use the repo URL
(instead of path). This preserves more information about the source
repository and allows bundles to be served through hgweb.
A test verifying that bundles can now be served properly via
`hg serve` has been added.
Recent change in the push process introduced an extra listing of the phase
name space before the push (on default). Meanwhile on default, a fix introduced
a new test with debug output.
We update the test output to be correct.
There are multiple possible cases for added files. But it's all handled by magic
much lower in the stack. We document them, simplify the codes and move on.
Before this patch, if both "--message" and "--collapse" are specified
for "hg rebase", "rebaes.normal" is used as "editform" unexpectedly.
Unlike patches before and after in this series for improvement, this
is bug fix patch.
At the external editor invocation for committing, the value specified
as "editform" for "cmdutil.getcommiteditor" is in "HGEDITFORM".
This enables external editor to do own customization according to
commit types.
Before this patch, linear merging of modified largefiles causes
an unexpected result, if (1) largefile collides with same-name normal one
in the target revision and (2) "local" largefile is chosen, even
though branch merging between such revisions works correctly.
Expected result of such linear merging is marking the largefile as
(re-)"added", but the actual result is marking it as "modified".
The standin of modified "local largefile" is not changed by linear
merging, and updating/merging update lfdirstate entries only for
largefiles of which standins are changed.
This patch adds the code path to update lfdirstate only for largefiles
of which standins are not changed.
In this case, "synclfdirstate" should be invoked with True as
"normallookup" argument always to force using "normallookup" on
dirstate for "n" files, because "normal" may mark target files as
"clean" unexpectedly.
To reduce cost of "lfile not in filelist", this patch converts
"filelist" to a "set" object: "filelist" is used only in (1) the newly
added code path and (2) the next line of "filelist = set(filelist)".
This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, "lfdirstate" should
be updated with "dirstate" simultaneously during "merge.update"
execution: maybe by hooking "recordupdates" (+ total refactoring
around lfdirstate handling)
Before this patch, linear merging of modified or newly added largefile
causes unexpected result, if (1) largefile collides with same name
normal one in the target revision and (2) "local" largefile is chosen,
even though branch merging between such revisions doesn't.
Expected result of such linear merging is:
(1) (not yet recorded) largefile is kept in the working directory
(2) largefile is marked as (re-)"added"
(3) colliding normal file is marked as "removed"
But actual result is:
(1) largefile in the working directory is unlinked
(2) largefile is marked as "normal" (so treated as "missing")
(3) the dirstate entry for colliding normal file is just dropped
(1) is very serious, because there is no way to restore temporarily
modified largefiles.
(3) prevents the next commit from adding the manifest with correct
"removal of (normal) file" information for newly created changeset.
The root cause of this problem is putting "lfile" into "actions['r']"
in linear-merging case. At liner merging, "actions['r']" causes:
- unlinking "target file" in the working directory, but "lfile" as
"target file" is also largefile itself in this case
- dropping the dirstate entry for target file
"actions['f']" (= "forget") does only the latter, and this is reason
why this patch doesn't choose putting "lfile" into it instead of
"actions['r']".
This patch newly introduces action "lfmr" (LargeFiles: Mark as
Removed) to mark colliding normal file as "removed" without unlinking
it.
This patch uses "hg debugdirstate" instead of "hg status" in test,
because:
- choosing "local largefile" hides "removed" status of "remote
normal file" in "hg status" output, and
- "hg status" for "large2" in this case has another problem fixed in
the subsequent patch
Before this patch, there is no explicit test for it: test-issue3084.t
seems to test such conflict only at branch merging.
This patch uses "[debug] dirstate.delaywrite" feature for the tests
expecting "M" status of largefiles, to confirm certainly whether files
are marked unexpectedly as "clean".
Using status information against the target ensures we are catching all
files with modifications that need reverting.
We still need to distinguish fresh modifications for backup purpose.
test-largefile is affected because it reverted a file that needs no content
change.
Tracking clean files is the simplest way to be able to reports files that need
no changes. So we explicitly retrieve them.
This fixes a couple of test outputs where the lack of changes was not reported.
The output is slightly changed because of minirst formatting. Previously,
ui.pushbuffer() had no effect because "badalias" message was written to stderr.
"if not unknowncmd" should no longer be needed because there's no call loop.
Before this patch, there was no way to pass in all the positional parameters as
separate words down to another command.
(1) $@ (without quotes) would expand to all the parameters separated by a space.
This would work fine for arguments without spaces, but arguments with spaces
in them would be split up by POSIX shells into separate words.
(2) '$@' (in single quotes) would expand to all the parameters within a pair of
single quotes. POSIX shells would then treat the entire list of arguments
as one word.
(3) "$@" (in double quotes) would expand similarly to (2).
With this patch, we expand "$@" (in double quotes) as all positional
parameters, quoted individually with util.shellquote, and separated by spaces.
Under standard field-splitting conditions, POSIX shells will tokenize each
argument into exactly one word.
This is a backwards-incompatible change, but the old behavior was arguably a
bug: Bourne-derived shells have expanded "$@" as a tokenized list of positional
parameters for a very long time. I could find this behavior specified in IEEE
Std 1003.1-2001, and this probably goes back to much further before that.
When a file was marked as removed in the working copy and did not existed in the
target of the revert, we did not issued any message pointing that no change was
needed to the file (implicitly saying that revert had changed the file).
We now properly issue a message in this situation. Tests change in and handful
of case where the message was documented as missing.
This new histedit command (short for "rollup") is a variant of "fold" akin to
"hg amend" for working copy: it accumulates changes without interrupting
the user and asking for an updated commit message.
Unlike untracked, the file is also missing from the working directory.
This test highlights a small misbehavior in output when reverting to another
revision.
We now also test reverting file to another revision's content. However
this differs from previously introduced test by using the explicit path
of each "case file" when calling revert. This should result in the
same result regarding file content and backup creation, but the output
of the `hg revert` call should differ.
We now also test reverting file to the working directory parent
content. However this differs from the previously introduced test by using
the explicit path of each "case file" when calling revert. This should
result in the same result regarding file content and backup creation,
but the output of the `hg revert` call should differ.
