On POSIX platforms, the 'add', 'addremove', 'copy' and 'rename' commands now
warn if a file has a name that can't be checked out on Windows.
Example:
$ hg add con.xml
warning: filename contains 'con', which is reserved on Windows: 'con.xml'
$ hg status
A con.xml
The file is added despite the warning.
The warning is ON by default. It can be suppressed by setting the config option
'portablefilenames' in section 'ui' to 'ignore' or 'false':
$ hg --config ui.portablefilenames=ignore add con.xml
$ hg sta
A con.xml
If ui.portablefilenames is set to 'abort', then the command is aborted:
$ hg --config ui.portablefilenames=abort add con.xml
abort: filename contains 'con', which is reserved on Windows: 'con.xml'
On Windows, the ui.portablefilenames config setting is irrelevant and the
command is always aborted if a problematic filename is found.
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
Currently, cmdutil.make_file() will return a freshly made file handle,
except when given a pattern of '-'. If callers would want to close the
handle, they would have to make sure that it's neither sys.stdin or
sys.stdout. Instead, returning a duplicate of either of the two
ensures that make_file() lives up to its name and creates a new
file handle regardless of the input.
Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
Regression from 9f0026001bfd. That previous commit is not supposed
to affect log calls without --follow, so we step out of this
codepath if follow is not True, and it's enough to fix the
regression.
When --follow is given, we fix the issue by taking into account
changesets that have a rev > maxrev to build the filegraph: even if
those files are not included in the final result, it's still needed
to walk correctly the graph from the end of the filelog to minrev, to
track accurately renames.
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.
