We should probably avoid strong quotes around command line args in the examples,
since cmd.exe doesn't recognize them, and it will surprise a user who cargo
cults them. I don't see a way to make a rule for this, since strong quoting is
OK inside command line args, like within revsets.
Future patches will make a node symbol templatable. Because arguments of a
templatekw function are repo and ctx, "showparents" list will have to be
built from a repo object by that function.
Before this patch, "hg import" executes below before acquisition of
wlock:
- cmdutil.checkunfinished()
- cmdutil.bailifchanged()
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
To avoid this issue, this patch executes 'cmdutil.checkunfinished()'
and 'cmdutil.bailifchanged()' inside wlock scope of "hg import".
Before this patch, "hg graft" executes below before acquisition of
wlock.
- cmdutil.checkunfinished()
- cmdutil.bailifchanged()
- repo.dirstate.parents() via 'repo["."]'
- unlinking '.hg/graftstate'
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
This patch widens wlock scope of "hg graft" for consitency while
processing.
Before this patch, "hg backout" executes below before acquisition of
wlock.
- cmdutil.checkunfinished()
- cmdutil.bailifchanged()
- repo.dirstate.parents()
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
In addition to it, "hg backout" refers changelog for purposes below
without acquisition of store lock (slock), and it may cause
unintentional result, if store is updated parallelly.
- show and update to the revision by 'repo.changelog.tip()'
- examine for "created new head" by 'repo.branchheads()' and
'cmdutil.commitstatus()'
To avoid this issue, this patch makes "hg backout" acquire wlock and
slock before processing.
Before this patch, "hg commit" (process A) executes steps below:
1. get current branch heads via 'repo.branchheads()'
- cache 'repo.changelog'
2. invoke 'repo.commit()'
3. acquire wlock
- invalidate 'repo.dirstate'
4. access 'repo.dirstate'
- re-read '.hg/dirstate'
- check validity of parent revisions with 'repo.changelog'
5. invoke 'repo.commitctx()'
6. acquire store lock (slock)
- invalidate 'repo.changelog'
7. do committing
8. release slock
9. release wlock
10. check new branch head (via 'cmdutil.commitstatus()')
If acquisition of wlock at (3) above waits for another "hg commit"
(process B) or so running parallelly to release wlock, process A
causes creating orphan revision, because:
- '.hg/dirstate' refers the revision, which is newly added by
process B, as its parent
- but already cached 'repo.changelog' doesn't contain such revision
- therefore, validating parents of '.hg/dirstate' at (4) above
replaces such revision with 'nullid'
Then, process A creates "orphan" revision, of which parent is "null"
revision.
In addition to it, "created new head" may be shown at the end of
process A unintentionally, if store is updated parallelly, because
both getting branch heads (1) and checking new branch head (10) are
executed outside slock scope.
To avoid this issue, this patch makes "hg commit" acquire wlock and
slock before processing.
This patch resolves the issue between "hg commit" processes, but not
one between "hg commit" and other commands. Subsequent patches resolve
the latter.
Even after this patch, there are still corner case problems below:
- filecache may overlook changes of '.hg/dirstate', and it causes
similar issue (see below for detail)
https://bz.mercurial-scm.org/show_bug.cgi?id=4368#c10
- 3rd party extension may cause similar issue, if it directly uses
'repo.commit()' without acquisition of wlock and slock
This can be fixed by acquisition of slock at the beginning of
'repo.commit()', but it seems suitable for "default" branch
In fact, acquisition of slock itself is already introduced at
"default" branch by ec227b188932, but acquisition is not at the
beginning of 'repo.commit()'.
This patch also changes some tests:
- test-fncache.t needs this tricky wrapping, to release (= forced
failure of) wlock certainly
- order of "hg commit" output is changed by widening scope of locks,
because some hooks are fired after releasing wlock
When debugrebuilddirstate --minimal is called, rebuilding the dirstate was done
outside of the appropriate rebuild function. This patch makes
debugrebuilddirstate use dirstate.rebuild.
This was done to allow our extension to become aware debugrebuilddirstate
--minimal
before, if you ran hg graft --user ... --date ... --log ... revs,
and if it failed, it would suggest "hg graft --continue",
but if you did that, your --user / --date / --log options
were lost, because they were not persisted anywhere...
localrepo.parents() has relatively few users, and most of those were
actually implicitly looking at the wctx, which is now made explicit
via repo[None].
The next patch will merge the cmdutil.service() calls of both commandserver
and hgweb. Before doing it, this patch wipes out the code specific to hgweb
from commands.serve().
This is so much easier to read than a long string of zeroes, and we're going to
have a lot more of these nodes once change/delete conflicts are part of the
merge state.
The merge from stable into default was semantically incomplete -- a couple of
changes in preceding code had to be rewritten here.
This code only triggers for change/delete conflicts, so we can't test it yet.
We will soon be able to do it, though.
Previously, we'd restore the .orig file after the premerge is complete but
before the merge was complete. This would lead to the .orig file potentially
containing merge conflict markers in it, as a leftover from the last merge
attempt.
We would normally use the read() constructor, but in this case it's fine
because
- we implement our own reading layer, so the extra parsing done by
read() is unnecessary
- read() can raise an exception for unsupported merge state records,
but here we'd like to handle that separately
- debugmergestate needs to be privy to mergestate internals anyway
Removes the named arguments and replaces them by accessing opts. This will be
used in the next patch in the series because we'll be adding more flags to
debugdirstate
See previous patch for why we're doing this.
We do this with a bit of care -- it would be bad form for 'hg summary' to abort
completely if we encounter an unsupported merge record. Instead just warn about
that and continue with the rest of the summary.
We're going to add a separate record type for change/delete conflicts soon. We
need to make sure they get stored with the correct record type so that older
versions of Mercurial correctly abort when they see change/delete records.
I have no idea where it came from, but my clone of Mercurial has an
empty filelog for `contrib/hgfixes/__init__.py` - it's *valid*, just
contains no nodes. Without this change, debugrevlog crashes with a
zero division error.
This can happen when either 'hg resolve --all' is called or a driver-resolved
file is explicitly requested.
This is done as part of 'hg resolve --all' so that users still have a chance to
test their changes before committing them.
The exact semantics here are still to be decided. This does not impact any
non-experimental features.
Thanks to Pierre-Yves David for some advice about this behavior in particular,
and merge drivers in general.
We need to be careful about allowing --mark and --unmark to keep working -- we
don't want the user to be stuck in a weird state. The exact behavior here is
still to be decided, though.
Users will often be in the habit of running 'hg resolve --mark --all' after
resolving merge conflicts in source files. We need to make sure this doesn't
cause driver-resolved files to be marked.
'hg resolve --all' will resolve driver-resolved files, though.
The weird conditional structure is to accommodate an upcoming patch.
Sometimes a basic type string is not sufficient for representing the
contents of a bundle. Take bundle2 for example: future bundle2 files may
contain parts that today's bundle2 parser can't read. Another example is
stream clone data. These require clients to support specific
repository formats or they won't be able to read the written files. In
both scenarios, we need to describe additional metadata beyond the outer
container type. Furthermore, this metadata behaves more like an
unordered set, so an order-based declaration format (such as static
strings) is not sufficient.
We introduce support for "parameters" into the bundle specification
string. These are essentially key-value pairs that can be used to encode
additional metadata about the bundle.
Semicolons are used as the delimiter partially to increase similarity to
MIME parameter values (see RFC 2231) and because they are relatively
safe from the command line (although values will need quotes to avoid
interpretation as multiple shell commands). Alternatives considered were
spaces (a bit annoying to encode) and '&' (similar to URL query strings)
(which will do bad things in a shell if unquoted).
The parsing function now returns a dict of parsed parameters and
consumers have been updated accordingly.
For the same reasons that we don't produce stream clone bundles with `hg
bundle`, we don't support consuming stream clone bundles with `hg
unbundle`. We introduce a complementary debug command for applying
stream clone bundles. This command is mostly to facilitate testing.
Although it may be used to manually apply stream clone bundles until a
more formal mechanism is (possibly) adopted.
Now that we have support for recognizing the streaming clone bundle
type, add a debug command for creating them.
I decided to create a new debug command instead of adding support to `hg
bundle` because stream clone bundles are not exactly used the same way
as normal bundle files and I don't want to commit to supporting them
through the official `hg bundle` command forever. A debug command,
however, can be changed without as much concern for backwards
compatibility.
As part of this, `hg bundle` will explicitly reject requests to produce
stream bundles.
This command will be required by server operators using stream clone
bundles with the clone bundles feature.
