Previously cmdutil.add would call wctx.walk(), which under the hood calls
dirstate.walk with full=True. This means it returns all of the clean files
(which we don't need when computing the add set), as well as the unclean files.
This results in 1) a lot more work being done and 2) this code path
circumventing the hgwatchman extension, resulting in worse performance in
hgwatchman environments ('hg add .' went from 9s to 1.8s).
Interactive committing under non-interactive mode shows command
suggestion, but sometimes it is meaningless.
command suggestion usability
------------ ---------- -----------
record commit
commit -i commit meaningless
qrecord qnew
qnew -i qnew meaningless
qrefersh -i qrefresh meaningless
shelve -i commit incorrect
------------ ---------- -----------
This patch allows callers of 'cmdutil.dorecord()' to omit meaningless
suggestion by passing None or so for 'cmdsuggest' argument of it.
This is a preparation for subsequent patches, which fix each
suggestion issues above.
Because flush() is the function to write data buffered by show(ctx),
flush(ctx) is more consistent than flush(rev). This makes sure that
buffered header and hunk are always keyed by ctx.rev().
This patch will allow us to give an integer to the wdir while keeping
wctx.rev() -> None.
Because we want to eliminate "if"s in the default template, it makes sense to
display wdirrev/wdirnode values for now. wdir() is still experimental, so the
output of "log -r'wdir()'" may change in future.
To detect change of a file without redundant comparison of file
content, dirstate recognizes a file as certainly clean, if:
(1) it is already known as "normal",
(2) dirstate entry for it has valid (= not "-1") timestamp, and
(3) mode, size and timestamp of it on the filesystem are as same as
ones expected in dirstate
This works as expected in many cases, but doesn't in the corner case
that changing a file keeps mode, size and timestamp of it on the
filesystem.
The timetable below shows steps in one of typical such situations:
---- ----------------------------------- ----------------
timestamp of "f"
----------------
dirstate file-
time action mem file system
---- ----------------------------------- ---- ----- -----
N *** ***
- change "f" N
- execute 'hg commit -i'
- backup "f" with timestamp N
- revert "f" by 'merge.update()' N
with 'partially'
- apply selected hunks N
by 'patch.patch()'
- 'repo.commit()'
- 'dirstate.normal("f")' N
N+1
- 'dirstate.write()' N N
- restore "f" N+1
- restore timestamp of "f" N
- 'hg status' shows "f" as "clean" N N N
---- ----------------------------------- ---- ----- -----
The most important point is that 'dirstate.write()' is executed at N+1
or later. This causes writing dirstate timestamp N of "f" out
successfully. If it is executed at N, 'parsers.pack_dirstate()'
replaces timestamp N with "-1" before actual writing dirstate out.
This issue can occur when 'hg commit -i' satisfies conditions below:
- the file is committed partially, and
- mode and size of the file aren't changed before and after committing
The root cause of this issue is that (maybe partially changed) files
are restored with original timestamp but dirstate isn't updated for
them.
To detect changes of files correctly, this patch applies
'dirstate.normallookup()' on restored files. Status check is needed
before 'dirstate.normallookup()', because status other than "n(ormal)"
should be kept at failure of committing.
This patch doesn't examine whether each files are committed fully or
partially, because interactive hunk selection makes it difficult.
After this change, timetable is changed as below:
---- ----------------------------------- ----------------
timestamp of "f"
----------------
dirstate file-
time action mem file system
---- ----------------------------------- ---- ----- -----
N *** ***
- change "f" N
- execute 'hg commit -i'
- backup "f" with timestamp N
- revert "f" by 'merge.update()' N
with 'partially'
- apply selected hunks N
by 'patch.internalpatch()'
- 'repo.commit()'
- 'dirstate.normal("f")' N
N+1
- 'dirstate.write()' N N
- restore "f" N+1
- restore timestamp of "f" N
----------------------------------- ---- ----- -----
- normallookup("f") -1
- release wlock
- 'dirstate.write()' -1 -1 N
----------------------------------- ---- ----- -----
- 'hg status' shows "f" as "clean" -1 -1 N
---- ----------------------------------- ---- ----- -----
To reproduce this issue in tests certainly, this patch emulates some
timing critical actions as below:
- change "f" at N
'touch -t 200001010000' before command invocation changes mtime of
"f" to "2000-01-01 00:00" (= N).
- apply selected hunks at N
'patch.internalpatch()' with 'fakepatchtime.py' explicitly changes
mtime of patched files to "2000-01-01 00:00" (= N).
- 'dirstate.write()' at N+1 (or "not at N")
'pack_dirstate()' uses actual timestamp at runtime as "now", and
it should be different from the "2000-01-01 00:00" of "f".
BTW, in 'test-commit-interactive.t', files are sometimes treated as
modified , even though they are just committed fully via 'hg commit
-i' and 'hg diff' shows nothing for them.
Enabling win32text causes EOL style mismatching below:
- files are changed in LF style EOL
=> files restored after committing uses LF style EOL (1)
- 'merge.update()' reverts files in CRLF style EOL
- 'patch.internalpatch()' changes files in CRLF style EOL
=> 'dirstate.normal()' via 'repo.commit()' uses the size of files
in CRLF style EOL (2)
Therefore, fully committed files are treated as "modified", because
'lstat()' returns size of (1) restored files in LF style EOL, but
dirstate expects size of (2) committed files in CRLF style EOL.
After this patch, 'dirstate.normallookup()' on committed files forces
subsequent 'hg status' to examine changes exactly, and fully committed
files are treated as clean as expected.
This is reason why this patch also does:
- add some 'hg status' checking status of fully committed files
- clear win32text configuration before size/timestamp sensitive examination
Before this patch, 'recordfunc()' for interactive hunk selection does
below outside wlock scope at 'hg commit -i' and so on:
- backup files, which may be partially changed
- apply selected hunks on files
- restore files from backup-ed ones
These should be executed inside wlock scope for consistency.
To put them into wlock scope without largely changing indents in
'recordfunc()', this patch adds another wrapper function.
This patch is also a preparation for subsequent patch fixing the issue
to correctly recognize partially committed files as "modified".
Explicit 'dirstate.normallookup()' invocation in 'revert()' is useless
now, because previous patch fixed the relevant issue by writing
in-memory dirstate changes out at the end of dirty check.
'dirstate.normallookup()' invocation was introduced by 1a735e934681 to
avoid occasional test failure (see issue4583 for detail). This is
partial backout of it (added tests are still left).
Because we defined the working-directory revision is INT_MAX, it makes sense
that "hg log -r 'wdir()'" displays the "parent:" field. This is the same for
two revisions that are semantically contiguous but the intermediate revisions
are hidden.
The value is used at multiple points in the function. Retrieving the
value in the middle of the transaction scope gives the false
impression that it has a single user. We move it at the start of the
function to clarify this.
There was code to move the bookmarks around both in the 'cmdutil' help and in
the main 'commit' function. We kill the 'commit' version as it is performed
outside the transaction.
The debug note is moved into cmdutil.
We have code moving bookmarks from the old changeset to the new one within the
transaction scope. Yet this code was still writing to disk instead of
handing the change to the transaction. This changeset fixes this.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
After the discussion on the list about hg revert -i, it seems like we are
satisfied with what we called proposition 2. It shows the changes to revert in
the same direction as hg diff. This patch makes it the default option.
It changes all the + in - and vice versa in the tests for revert -i.
We want to share this function between formatter and cmdutils. It
doesn't belong in templater because it imports knowledge of ui layers
that shouldn't be there. We'd prefer cmdutil to layer on the formatter
rather than vice-versa. Since the formatter is the handler for -T
options for all non-log commands, let's move the helper there. We
leave the bits specific to the old --style option behind.
The previous code didn't restore the original method, but it looks like the
worst that would happen is junk added to a list that had already been processed
by previous subrepo invocation(s).
The previous code didn't restore the original method, but it looks like the
worst that would happen is junk added to a list that had already been processed
by previous subrepo invocation(s).
We had a discussion on the list about the interactive ui for revert. This patch
adds a flag to allow people to test the second alternative (referred to as
proposition 2 on the mailing list). It effectively inverts the signs in the
This patch is part of a series of patches to change the recording ui to reflect
the operation currently running (commit, shelve, revert ...).
This patch adds a new argument to the recording function to reflect in the UI
what operation we are running.
Before this patch: editing hunks of newly added file when performing a revert
--interactive had no effect: the edits were discarded.
After this patch, the edits are taken into account.
This allows us to use existing code to detect files that are newly added and
modified. In turn, this allows us to make revert --interactive support
editing newly added and modified files.
It should be possible to debug the submanifest revlogs without having
to know where they are stored (in .hg/store/meta/), so let's add a
--dir option for this purpose.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Previously import used force=partial to allow empty commits to be made. Let's
switch it to using the new ui.allowemptycommit option. Tests says we can drop
the 'force' argument in the processs.
To fix the issue that the recent (in memory) dirstate isn't visible to
external process (e.g. "precommit" hook), a subsequent patch makes
"localrepository.commit()" invoke "dirstate.write()" in it.
This change will make "beginparentchange()" and "endparentchange()" on
dirstate in "cmdutil.tryimportone()" meaningless, because:
- "dirstate.write()" writes changed data into ".hg/dirstate", but
- aborting between "beginparentchange()" and "endparentchange()"
doesn't cause any restoring ".hg/dirstate"
it just discards changes in memory.
This patch uses "dirstateguard" instead of "beginparentchange()" and
"endparentchange()" in "cmdutil.tryimportone()" to restore
".hg/dirstate" during a failure even if "dirstate.write()" is executed
before a failure.
This patch uses "lockmod.release(dsguard)" instead of
"dsguard.release()", because processing may be aborted before
assignment to "dsguard" , and the "if dsguard" examination for safety is
redundant.
Before this patch, "cmdutil.amend()" uses "dirstate.invalidate()" as a
kind of "restore .hg/dirstate to the original status" during a failure.
But it just discards changes in memory, and doesn't actually restore
".hg/dirstate". Then, it can't work as expected, if "dirstate.write()"
is executed while processing.
This patch uses "dirstateguard" instead of "dirstate.invalidate()" to
restore ".hg/dirstate" at failure even if "dirstate.write()" is
executed before failure.
This is a part of preparations to fix the issue that the recent (in
memory) dirstate isn't visible to external process (e.g. "precommit"
hook).
Before this patch, after "dirstate.write()" execution, there was no way to
restore dirstate to the original status before "dirstate.write()".
In some code paths, "dirstate.invalidate()" is used as a kind of "restore
.hg/dirstate to the original status", but it just avoids writing changes in
memory out, and doesn't actually restore the ".hg/dirstate" file.
To fix the issue that the recent (in memory) dirstate isn't visible to external
processes (e.g. "precommit" hooks), "dirstate.write()" should be invoked before
invocation of external processes. But at the same time, ".hg/dirstate" should be
restored to its content before "dirstate.write()" during an unexpected failure
in some cases.
This patch adds the class "dirstateguard" to easily restore ".hg/dirstate"
during unexpected failures. Typical usecase of it is:
# (1) build dirstate up
....
# (2) write dirstate out, and backup ".hg/dirstate"
dsguard = dirstateguard(repo, 'scopename')
try:
# (3) execute somethig to do:
# this may imply making some additional changes on dirstate
....
# (4) unlink backed-up dirstate file at the end of dsguard scope
dsguard.close()
finally:
# (5) if execution is aborted before "dsguard.close()",
# ".hg/dirstate" is restored from the backup
dsguard.release()
For this kind of issue, an "extending transaction" approach (in
https://titanpad.com/mercurial32-sprint) seems to not be suitable, because:
- transaction nesting occurs in some cases (e.g. "shelve => rebase"), and
- "dirstate" may be already modified since the beginning of OUTER
transaction scope, then
- dirstate should be backed up into the file other than
"dirstate.journal" at the beginning of INNER transaction scope, but
- such alternative backup files are useless for transaction itself,
and increases complication of its implementation
"transaction" and "dirstateguard" differ from each other also in "what
it should do for .hg/dirstate" in cases other than success.
============== ======= ======== =============
type success fail "hg rollback"
============== ======= ======== =============
transaction keep keep restore
dirstateguard keep restore (not implied)
============== ======= ======== =============
Some collaboration between transaction and dirstate will probably be introduced
in the future. But this layer is needed in all cases.
Previously this function accepted two optional parameters that were unused by
any callers and complicated the function.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
