We highlight the behavior tested by each sections. (This is a gratuitous
improvement before significant upgrade of the test and massive refactoring of
the revert code)
Before this patch, after successful "hg rebase" of the revision
removing largefiles, "hg status" may still show ""R" for such
largefiles unexpectedly.
"lfilesrepo.commit" executes the special code path for automated
committing while rebase/transplant, and lfdirstate entries for removed
files aren't updated in this code path, even after successful
committing.
Then, "R" entries still existing in lfdirstate cause unexpected "hg
status" output.
This patch synchronizes lfdirstate with dirstate after automated
committing.
This patch passes False as "normallookup" to "synclfdirstate", because
modified files in "files()" of the recent (= just committed) context
should be "normal"-ed.
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. Hooking "markcommitted" of
ctx in "localrepository.commitctx" may achieve this.
This problem occurs, only when (1) the parent of the working directory
is rebased and (2) it removes largefiles, because:
- if the parent of the working directory isn't rebased, returning to
the initial revision (= update) after rebase hides this problem
- files added on "other" branch (= rebase target) are treated not as
"added" but as "modified" (= "normal" status and "unset"
timestamp) at merging
This patch tests also the status of added largefile, but it is only
for avoiding regression.
In addition to conditions above, "hg status" must not take existing
files to reproduce this problem, because existing files make
"match._files" not empty in "lfilesrepo.status" code path below:
def sfindirstate(f):
sf = lfutil.standin(f)
dirstate = self.dirstate
return sf in dirstate or sf in dirstate.dirs()
match._files = [f for f in match._files
if sfindirstate(f)]
Not empty "match._files" prevents "status" on lfdirstate from
returning the result containing problematic "R" files.
This is reason why "large1" (removed) and "largeX" (added) are checked
separately in this patch.
Problematic code path in "lfilesrepo.commit" is used also by "hg
transplant", but this problem doesn't occur at "hg transplant",
because invocation of "updatelfiles" after transplant-ing in
"overridetransplant" causes cleaning lfdirstate up.
This patch tests also "hg transplant" as same as "hg rebase", but it
is only for avoiding regression.
Before this patch, newly added (but not yet committed) largefiles
aren't treated as unknown ("?") after "hg rollback".
After "hg rollback", lfdirstate still contains "A" status entries for
such largefiles, even though corresponding entries for standins are
already dropped from dirstate.
Such "orphan" entries in lfdirstate prevent unknown (large)files in
the working directory from being listed up in "unknown" list. The code
path in "if working" route of "lfilesrepo.status" below drops
largefiles tracked in lfdirstate from "unknown" list:
lfiles = set(lfdirstate._map)
# Unknown files
result[4] = set(result[4]).difference(lfiles)
This patch drops orphan entries from lfdristate at "hg rollback".
This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, lfdirstate should
be rollback-ed as a part of transaction, as same as dirstate.
Before this patch, removed or forgotten largefiles aren't treated as
removed ("R") after "hg rollback". Removed ones are treated as missing
("!") and forgotten ones are treated as clean ("C") unexpectedly.
"overriderollback" uses "normallookup" to restore status in lfdirstate
for largefiles other than ones not added in rollback-ed revision, but
this isn't correct for removed (or forgotten) largefiles.
This patch uses "lfutil.synclfdirstate" to restore "R" status of
removed (or forgotten) largefiles correctly at "hg rollback".
This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, lfdirstate should
be rollback-ed as a part of transaction, as same as dirstate.
Before this patch, there are three distinct "wlock" scopes in
"overriderollback":
1. "localrepository.rollback" via original "rollback" command,
2. "merge.update" for reverting standin files only, and
3. "overriderollback" specific "wlock" scope (to synchronize
largefile dirstate)
But these should be executed in the same "wlock" scope for
consistency.
The phase cache file is no longer written on lock release, it is now handled by
the transaction (as changesets and obsolescence markers are).
(Hooray)
As we stop relying on the lock to write phase, repos with no existing phase
information will need to wait for a phase move or a strip to happen in order to
get the first write in the `phaseroots` file. This explain the change in
test-inherit-mode.t.
This should not have any side effects but in very obscure cases where
people interact with pre-2.1 and post-2.1 versions of Mercurial on the
same repo while having MQ patches applied but the MQ extension
disabled from time to time. A case unlikely enough to not be worth
preserving the old behavior with awful hacks.
In most case, the file creation logic will be handled by the
transaction itself. The write method has to stay around for the case
where the repository is modified outside a transaction (strip).
A new `transaction.addfilegenerator` function is added. It allows external code
to register files to be generated. See inline documentation for details.
It is important to gather all file creation logic on the transaction
as at some point we'll want to mimic the "pre-transaction-commit"
logic that we use for revlog. I'm refering to the logic that lets
hooks see the result of the transaction before it actually gets
committed.
Similar to the previous patch for workingfilectx, this patch will allow
abstracting localrepo.remove / write method to refactor working directory code
but instead operate on files in memory.
Python 2.7.7 and later (as well as some ubuntu/debian packages of
2.7.6) include a fix that makes the email module more pedantically
correct for MIME boundaries, but this breaks our tests. We work around
this by filtering the output of any 'hg email' invocations in the test
that produce MIME messages.
We now pass a transaction option to this phase movement function. The
object is currently not used by the function, but it will be in the
future.
All call sites have been updated. Most call sites were already enclosed in a
transaction for a long time. The handful of others have been recently
updated in previous commit.
We now pass a transaction option to this phase movement function. The object
is currently not used by the function, but it will be in the future.
All call sites have been updated. Most call sites were already enclosed in a
transaction for a long time. The handful of others have been recently
updated in previous commit.
The retractboundary function remains to be upgraded.
We were relying on the phase internals to filter out redundant phase
information from remove. However as we plan to integrate phase
movement inside the transaction, we want to avoid useless transaction
creation on no-op pulls.
Therefore we filter out all the information that already matches the current
repository state. This will let us create a transaction only when there is
actual phase movement needed.
We introduce a test-check-commit-hg.t file that will happily run the
check-commit file on all draft changeset under the working directory.
This should help newcomers to catch up with the rules. (And will helps old timer
from time to time).
cset 21b4faf3787e has removed this option. This commit just tidies the
code that was associated to it. It also fixes the internal calls to
the strip() function.
Before this change, any function that thought it would want as a final
safety to keep a partial backup bundle (bundling changes not linearly
related to the current change being stripped), had to explicitly pass
a backup="strip" option. With this change, these backups are always
kept in case of an exception and always removed if there is no
exception. Only full backups can be specified with backup=True or no
full backups with backup=False.
The following functions in simplemerge are dead code. I reran "make
test-merge*" after this change, and it passed. Looks like cruft that
we've been carrying since we nabbed this code from bzr.
This fixes a discrepency for basectx and classes that inherit from it. Now
callers can pass these arguments to any context without an exception being
raised.
The Jenkins CI system understands xunit reports natively, so this will
be helpful for anyone that wants to use Jenkins for testing hg or
extensions that use run-tests.py for their testing.
This argument controls the phase used for the added changesets. This can be
useful to unbundle in "secret" phase as required by shelve.
This change aims at helping high-level code get rid of manual phase
movement. An important milestone for having phases part of the transaction.
We rely on the internal mechanism to commit the changeset in the right state.
This is similar to what the mq extension is doing.
This is an important change as we plan to move phase movement with the
transaction. Avoiding phase movement from high level code will avoid them the
burden of transaction handling. It is also important to limit the need for
transaction handling as this limits the odds of people messing up. Most common
expected mess-up is to use a different transaction for changesets creation and
phase adjustment.
We rely on the internal mechanism to commit the changeset in the right phase.
This similar to what the mq extension is doing.
This is an important change as we plan to includes phase movement within the
transaction. Avoiding phase movement from high-level code will avoid the
burden of transaction handling. It is also important to limit the need for
transaction handling as this limits the odds of people messing up. Most common
expected mess-up is code using a different transaction for changeset creation
and phase adjustment.
