To make histedit action objects responsible for understanding
the format of their action lines we are adding a torule method
which for a histedit action will return a string which can be
saved in histedit state or shown in text editor when editing the
plan.
This commits splits the parsing of the histedit rule from its semantic analysis.
It's necessary because sometimes we want to do first without doing the former (reading the
histedit state).
This decorator will is allowing us to move the registering the action
in actiontable closer to the action code. Also it is storing the
verb inside histedit action so the action is aware of the verb
needed to trigger it.
I want to refactor histedit to use action objects instead of (verb, rest)
pairs whenever possible. At the end of this series I want the rules to
be translated into action objects when reading state and translated back
when writing state. All histedit internals should use action objects instead
of state rules.
To migrate histedti internals sequentially I'm introducing the state.actions
property to translate rules on the fly so we can use both state.actions and
state.rules until refactoring is done.
The pull url header can easily grow over 80 chars. The check-commit script was
confusing this with a too long summary line. We update the regular expression to
not match other header.
Before this patch, "hg shelve" of shelve extension executes
'cmdutil.checkunfinished()' before acquisition of wlock.
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
To avoid this issue, this patch executes 'cmdutil.checkunfinished()'
inside wlock scope of "hg shelve".
This also fixes issue4957, because now 'cmdutil.checkunfinished()'
isn't invoked at "hg shelve" with options below:
--cleanup
--delete
--list
--patch
--stat
Before this patch, "hg shelve" of shelve extension executes/refers
below before acquisition of wlock:
- 'repo.dirstate.parents()' via 'repo[None].parents()'
- 'repo._activebookmark'
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
This patch widens wlock scope of "hg shelve" of shelve extension for
consistency while processing.
Before this patch, "hg sign" of gpg extension executes/evaluates below
without acquisition of wlock.
- repo.dirstate.parents()
- '.hgsigs' not in repo.dirstate
It may cause unintentional result, if another command runs parallelly
(see also issue4368).
To avoid this issue, this patch makes "hg sign" of gpg extension
acquire wlock before processing.
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
We unify the delta selection process to be a simple three options process:
- try to use the incoming delta (if lazydeltabase is on)
- try to find a suitable parents to delta against (if gd is on)
- try to delta against the tipmost revision
The first of this option that yield a valid delta will be used.
The test change in 'test-generaldelta.t' show this behavior as we use a delta
against the parent instead of a full delta when the incoming delta is not
suitable.
This as some impact on 'test-bundle.t' because a delta somewhere changes. It
does not seems to change the test semantic and have been ignored.
The currently used manifest is too small and cannot sustain a chain length
above "1". This make testing the 'lazybasedelta' behavior hard. So we add an
extra file in the manifest to help testing in the next changeset.
The semantic of existing tests have been checked and is not changed.
The old code have multiple explicit tests and code duplications. This makes it
hard to improve the code. We rewrite the logic in a more generic way, not
changing anything of the computed result.
The final goal here is to eventually be able to:
- factor out the default fallback case "try against 'prev'" in a single place
- allow 'lazydeltabase' case to use the smarter general delta code path when
the incoming base does not provide us with a good delta.
I'm about to move active-bookmark management into the bmstore. I'd
like to avoid re-writing the bookmarks data (as distinct from the
active bookmark file) if possible, so let's introduce some
dirty-tracking early.
Previously, when extdiff was called on two changesets where
a subrepository had been removed, an unexpected KeyError would
be raised.
Now, the missing subrepository will be ignored. This behavior
mirrors the behavior in diffordiffstat from cmdutil.py line
~1138-1153. The KeyError is caught and the revision is
set to None.
try/catch of LookupError around matchmod.narrowmatcher and
sub.status is removed, as LookupError is not raised anywhere
within those methods or deeper calls.
Before this patch, it was unclear why the httpservice object could read the
server options (e.g. --port) from 'ui'. It just worked because repo.ui is ui.
Since createservice() was moved to hgweb and hgweb imports both hgweb_mod and
hgwebdir_mod, we no longer have to force hgweb() function to select one of
them by the type of 'o' variable. Let's be explicit!
This patch does not change hgweb() function because it is the interface of
existing WSGI and CGI scripts.
Before this change, the 'lazydeltabase' would blindly build a delta using the
base provided by the incoming bundle and try to use it. If that base was far
down the revlog, the delta would be seen as "no good" and we would fall back to
a full text revision.
We now check if the delta is good and fallback to a computing a delta again the
tipmost revision otherwise (as we would do without general delta).
Later changesets will improve the logic to compute the fallback delta using the
general delta logic.
We would like to be able to exit the delta generation block without a valid
delta (for a more flexible control flow). So we make sure we do not expand the
"delta" content unless we actually have a delta.
We can do it one level lower because 'delta' is initialised at None anyway. Not
adding a level to the assignment prevent a line length issue.
When strip builds the list of changedfiles to pass into dirstate.rebuild, it adds
files blindly, including those that have been removed. This tests ensures that
rebuild can handle this case.
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
Debugging the dirstate helps if you have options to add files for normal lookup
or drop them from the dirstate. This patch adds a convenience command to
test-rebuilddirstate.t to modify the dirstate. It will be used in the next patch
to write proper tests for 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...
Users may spend a lot of effort writing histedit rules,
getting an abort without being told they can recover their work
is very frustrating.
Avoid that by telling them where to find their work.
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].
It makes far more sense to leave these conflicts unresolved and kick back to
the user than to just assume that the local version be chosen. There are almost
certainly buggy scripts and applications using Mercurial in the wild that do
merges or rebases non-interactively, and then assume that if the operation
succeeded there's nothing the user needs to pay attention to.
A block of code above this one already says "if fctx is not None", and it's
also what this code actually intends to check, so let's be specific as PEP-8
recommends.
c0ebd60607e9 didn't remove it, let's do it now.
Placing the added lines into the already existing "if fctx is not None" block
also makes webcommands.comparison() look a bit more like
webcommands.filediff(), which eases possible future refactoring. And fctx is
not None only when path in ctx, so logically it's equivalent.
When comparing a file that was removed at the current revision, parents used to
show grandparents instead, due to how fctx was "shifted" from the current
revision to its p1. Let's not do that.
The fix is pretty much copied from webcommands.filediff().
Before this patch we were using the deprecated bookmarks.write api. This
patch replaces the call to bookmarks.write by a call to bookmarks.recordchange.
We move the bookmark code above the code removing the undo file because with
bookmarks.recordchange we have to create a transaction that would create an
undo file.
When I moved crecord into core, I didn't include the toggleAmend function (to
switch from commit to amend mode). I did it because it would have made it more
difficult to use record and crecord interchangably. This patch reintroduces the
amend mode for commit -i as well as two tests to verify the behavior of the
function.
