Even with --removed, it does not make sense to examine changesets outside
of the revision range that was specified by the user: the last phase only
yields a subset of (revs), preparation phase hence only has to examine
(revs) to fill correctly fncache.
The revrange function was used further up, and when a local variable
is defined with the same name, the earlier call to revrange becomes a
'local variable used before assignment' error.
The clash was introduced in 3544b3baebb0.
When in the slowpath, we are examining _all_ changesets in revs.
We need to order reads so they happen increasingly for I/O performance.
Increasing windows were used to read changelog backwards in a windowed manner,
reading the changelog forward inside each window. But since no revision range
was specified, it was equivalent to reading the full changelog, even if a
single revision was passed to the commandline.
When --removed is used, we _need_ to scan all changesets, but if we're only
looking for file patterns, this is not necessary and we can stick to
the revspec that was given to us.
The purpose of increasing windows is to allow backwards iteration on the
filelog at a reasonable cost.
But is it needed?
- if follow is False, we have no reason to iterate backwards.
We basically just want to walk the complete filelog and yield all revisions
within the revision range. We can do this forward or
backwards, as it only reads the index.
- when follow is True, we need to examine the contents of the filelog, and to
do this efficiently we need to read the filelog forward.
And on the other hand, to track ancestors and copies, we need to process
revisions backwards. But is it necessary to use increasing windows
for this?
We can iterate over the complete filelog forward, stack the revisions, and
read the reversed(pile), it does the same thing with a more readable code.
In commands.log a displayer was initialized from
cmdutil.show_changeset() with the initial matchfn (which designates
the specified files which only is correct in the highest revision in
the range). prep() is handed the correct list of files, but
displayer.show() didn't use that list but keept using the original
matchfn.
The matchfn argument to cmdutil.show_changeset() wasn't specified in
other places and is only used in .show(), so now we give the matchfn
as an optional parameter to .show().
We do however still have to detect --patch and --stat from opts in
show_changeset() and let it imply a matchall, but that can now be
overruled with the new .show() matchfn parameter.
I routinely want to use `hg addrem` and then fix up missed renames
manually using `hg mv -A`. This patch allows me to record such
renames from a source in state R to a target in state A.
bisect: clarify None return
bundle: return 1 on no changes
clone: return result code
copy: limit errors to 0/1
commit: return 1 on no changes
forget: return 1 on errors
grep: return 1 if no match found
remove: return 1 on errors
resolve: return 1 if something fails to resolve
rollback: return 1 if no rollback data
Currently running 'hg rename --after foo.txt bar.typo' is a silent no-op. This patch adds a warning. It also updates the copy and rename tests.
No actual functionality is changed.
fixes issue 1822
The next few patches will increase the size of the "findrenames"
functionality. This patch simply moves the function into its own
file to avoid clutter building up in 'cmdutil.py'.
The file-based synchronization introduced by 670de588e29e hangs when the child
process fails before terminating the handshake, which the previous pipe-based
version handled correctly. To fix this, the parent polling loop was fixed to
detect premature terminations of the child process.
Hiding the child process window is not strictly necessary but it avoids opening
an empty shell window when running hg serve as well as a task in the task bar.
The window is hidden after the process is already started causing a single
flicker.
On Windows, Mercurial can be run from the python script of from a frozen
executable. In the first case, we have to call the python interpreter since the
script is not executable. Frozen executable can be called directly.
Fix 3/3 for issue421
The fact that a parent process spawns a daemon does not necessarily means that
it is the only think it has to do. This was forcing since e8efd88001e7 inotify
processes launched implicitely to exit prematurely:
when no inotify server was running, "hg st" for example would only launch a
inotify server, _exit(0) and thus would not return file statuses.
This changeset adds a test for implicitely launched inotify processes.
Change to output of test-inotify-1208 is correct: it reflects the normal
error message of "hg st" when not dying during "hg inserve" daemon creation.
- use ctx.branch() instead of directly accessing the extra field "branch"
- move definitions of locals ('extra' and 'branch') down to where they
are used
This allows extensions that modify changeset metadata (e.g.
description) by overriding methods of changectx to get consistent
behavior from all log-like commands, regardless of whether templates
or styles are used. Without this, overriding changectx methods works
if you use styles or templates, but not with default log format.
This meant adding filectx.extra() for consistency with changectx.
This can be used for referring to revisions in a reasonable
meaningful, stable and monotonically increasing way, suitable for
releases or builds directly from a repository.
The latest tag is found by searching through untagged ancestors and
finding the latest tagged ancestor based on tag date. The distance is
found from the length of the longest path to the tagged revision.
For example:
hg log -l1 --template '{latesttag}+{latesttagdistance}\n'
can return
1.3.1+197
This is mostly work by Gilles Moris <gilles.moris@free.fr>
On Windows, Mercurial tries to glob expand provided filenames as a
convenience to the user. Unfortunately, there are valid filenames
which are not valid glob patterns. In those cases, we should fallback
to the original provided filename.
There is no standard python command to really detach a process under Windows.
Instead we use the low level API wrapped by subprocess module with all
necessary options to avoid any kind of context inheritance. Unfortunately, this
version still opens a new window for the child process.
The following have been tried:
- os.spawnv(os.P_NOWAIT): works but the child process is killed when parent
console terminates.
- os.spawnv(os.P_DETACH): works on python25, hang on python26 when writing to
the hgweb output socket.
- subprocess.CreateProcess() hack without shell mode: similar to
os.spawnv(os.P_DETACH).
Fix 1/3 for issue421
Semantically, it is better to use None over any other value when there is
"no value". Using maxint in this context is quite hackish, and is not forward
compatible.
Before this, to display file copies in templates, you had to write something
like {file_copies%filecopy}. For some reason, the {file_copy} subtemplate was
used by default but not defined by default in changeset_templater, while styles
were already using it. Here we define {file_copy} in changeset_templater, and
change the templater to handle formatting strings like {file_copies%filecopy}
with already expanded keys (in this case {file_copies}), for backward
compatibility.
{file_copies} template now displays file copies with or without the --copies
switch being set. A new {file_copies_switch} template implements the former
behaviour.
benchmarked with hg log -qf on the linux kernel:
before:
Time: real 39.010 secs (user 38.840+0.000 sys 0.060+0.000)
after:
Time: real 8.560 secs (user 8.440+0.000 sys 0.080+0.000)
benchmarked on crew repo with:
rm -rf * ; hg up -C ; for i in `find . -name "*.py"` ; do mv $i $i.new;done
followed by:
hg addremove -s 100
before: Time: real 28.890 secs (user 26.920+0.000 sys 1.450+0.000)
after : Time: real 6.790 secs (user 5.310+0.000 sys 1.350+0.000)
Getting the file from the working dir is less expensive than getting it from
the repo history, hence the speedup.
benchmarked on crew repo with:
rm -rf * ; hg up -C ; for i in `find . -name "*.py"` ; do mv $i $i.new;done
followed by:
hg addremove -s 100
before: Time: real 68.760 secs (user 65.760+0.000 sys 2.490+0.000)
after : Time: real 28.890 secs (user 26.920+0.000 sys 1.450+0.000)
Instead of only finding similarities in the added/removed files found
by the addremove step, follow the match object:
hg addremove -s80 foo -> add and removes files in foo
+ find similarities between files in foo
hg addremove -s80 -> add and removes files in the whole repo
+ find similarities between files in the whole repo
hg import --similarity will still work correctly (only find similarities
between files found in the patch).
hg export -o outfile 1 2 3 4 had the same effect as hg -o outfile 4
This was caused by opening with 'w' instead of 'a'. This only occurs when
the filename pattern resulted in ambiguous patch filenames.
