Since c06eb45e85a7, mq saves the nodeid of the first applied patch to
cache/branchheads, which breaks the optimized cache handling introduced in
1808e27e1362. The problem is the revision being committed is appended to
mqrepo.applied after the commit succeeds, which means mqrepo._branchtags()
performs a regular update and write the first applied patch to the branch
cache.
One solution is to set a context variable _committingpatch on the mqrepo while
it is committing a patch and to take it in account when deciding to fast-path
mqrepo._branchtags(). Not really elegant but it works.
The changes to test-mq-caches.t reverse changes introduced by c06eb45e85a7. The
cache should not have been updated with mq records.
The changes to test-keyword.t are indirectly caused by c06eb45e85a7.
Reported and analyzed by Yuya Nishihara <yuya@tcha.org>
Notes:
- qpush still makes a slow path _branchtags() call when checking heads. Maybe
this can be optimized.
- be careful when merging this patch in default as secretcommit() was renamed
newcommit() right after the end of the code freeze.
The current behaviour is to return the previous one in the series but at the
same time the implementation is buggy because it does not take guarded patches
in account.
This was breaking my remotebranches extension in a completely
mystifying way, because repo.lookup was failing to resolve the
statusentry. I'm not sure how this works absent my remotebranches
extension, but doing it this way looks more correct and doesn't break
anything.
When mq changeset are secret, they don't appear in outgoing and won't be
pushed. So it's not necessary to abort the push.
The checkpush call is protected by lock to prevent race on phase.
As mq automatically sets changesets as secret, it should make them draft when he
is done with it. We do not move them automatically to draft when we detect that
something else have also set them as secret through their parents.
Before the code optimistically relied on savedirty not being called a cancelled
transaction. If it was called it could save incorrect data.
Instead we now start using the invalidate method introduced in 469ecb6e5f24.
It wasn't obvious from the code how qsave mocked around with .hg/patches and
.hg/patches.? and what was going on.
This makes it more explicit so it will survive future refactorings.
When renaming a patch A as B where B was previously qfolded into A and
therefore marked as removed, a versioned MQ would first restore B before
marking it as a copy of A, thus losing A changes. The undelete() call is
probably a left-over, wctx.copy() explicitely handles the case where the
destination is removed.
Also note that status command represents "hg rm b; hg mv a b" as:
A b
a
R a
which explains the first hunk in test-mq-qrename.t.
Patch specifications in mq is passed around as a string or None. None is
generally used when no patch has been specified and there thus is nothing to
lookup and the calling code should do something else. One code path did however
pass None all the way to lookup. That case was handled in lookup, but there was
really need for that, it was undocumented, and it used to cause trouble back
when patches was specified as integers.
Most of the code paths in mq would always pass patch specifications as a
string. Patches can be specified by their index, but one code path passed that
(through pop) to lookup as an integer - all other code paths used a string.
Unfortunately pop and lookup (like many other parts of mq) used the boolean
value of the patch specification to see if it was None, and they would thus
incorrectly handle patch 0 as None.
This patch makes the code comply with the actual internal duck typing of patch
specifications: patch indices must be encoded as strings. The (now) unused code
for partial and thus incorrect handling of indices as integers is removed.
The usual contract is that close() makes your writes permanent, so
atomictempfile's use of close() to *discard* writes (and rename() to
keep them) is rather unexpected. Thus, change it so close() makes
things permanent and add a new discard() method to throw them away.
discard() is only used internally, in __del__(), to ensure that writes
are discarded when an atomictempfile object goes out of scope.
I audited mercurial.*, hgext.*, and ~80 third-party extensions, and
found no one using the existing semantics of close() to discard
writes, so this should be safe.
The new behavior was breaking existing tools that relied on a sequence such as
this:
1) start with a dirty working copy
2) qimport some patch
3) try to qpush it
4) old behavior would fail at this point due to outstanding changes.
(new behavior would only fail if the outstanding changes and the patches
changes intersect)
5) innocent user qrefreshes, gets his local changes in the imported patch
It's worth considering if we can move this behavior to -f in the future.
The most appropriate context is not always clearly defined. The obvious cases:
For working directory commands, we use None
For commands (eg annotate) with single revs, we use that revision
The less obvious cases:
For commands (eg status, diff) with a pair of revs, we use the second revision
For commands that take a range (like log), we use None
Because q.refresh() changes nodeid, .hg/patches/status gets invalid until
q.savedirty(). This patch changes mq not to unlock repository of incomplete
state.
