This gives the repository control over which nested repository paths
that should be allowed via the custom path auditor.
Since paths into subrepositories are now allowed, dirstate.walk must
now filter away more paths than before.
== What ==
issue732 is only one example of a buggy behaviour, but there are in fact many
intricated cases. For example:
( "o" contains an alive version of the tracked file, "x" does not)
tip - o - o - x - o - o - x ...
\
o - o - o - o - x ...
\ /
o - o
This repository contains at least two instances of the tracked file, but
when calling "hg log -f file" only the latest one (the one alive in tip)
matters to us.
== How ==
We must extract from the filelog the history of the file instance we're
interested in and discard changes related to other instances of that file.
We see that we're only interested in ancestors(node), and that all
other nodes in the filelog should not be considered.
The same variable is defined a few blocks earlier. The first phases in
walkchangerevs should in fact fill that cache, and allow faster lookups
in the last phase. Redefining and overriding this cached function, (knowing
that it will be called with the same arguments) defeats the caching purpose.
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'.
