This makes it possible to switch most win32text configurations (i.e. those
that use cleverencode and cleverdecode) to hgeol simply by disabling one and
enabling the other. Any rules found in repo-specific .hgeol files will be
appended to the configuration in .hgrc.
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.
According to the API document, GetModuleFileName is the preferred way to
retrieve the filename of the current process. So we shouldn't try
GetModuleFileName'Ex' first.
Previously system_rcpath_win32() happened to return unicode paths due to
GetModuleFileNameEx (issue2480). This problem is fixed as GetModuleFileName
never return unicode.
While this situation should never under normal use, some real
life repos sometimes contain such changesets (older hg versions,
broken rebases, etc...)
hgweb was displaying an "Internal error" in this case, and graphlog
displayed a redundant branch all the way to null: it does not cost us
much to just ignore this extra parent when constructing the DAG.
This makes test output less ambiguous.
Failing test output will be escaped and marked up if necessary. A Python
string-escape compatible encoding is used, but not everything is encoded -
especially not \n and \t and '.
Output chunks without a trailing LF will now work but get (no-eol) appended.
This change mostly moves code around so we can handle that an output line
starts with data from previous command, followed by salt and the next command.
The Linux CIFS kernel driver (even in 2.6.36) suffers from a hardlink
count blindness bug (lstat() returning 1 in st_nlink when it is expected
to return >1), which causes repository corruption if Mercurial running
on Linux pushes or commits to a hardlinked repository stored on a Windows
share, if that share is mounted using the CIFS driver.
This patch works around issue1866 and improves the workaround done in
65e082ae3076 to fix issue761, by teaching the opener to lazily execute a
runtime check (new function checknlink) to see if the hardlink count
reported by nlinks() can be trusted.
Since nlinks() is also known to return varying count values (1 or >1)
depending on whether the file is open or not and depending on what client
and server software combination is being used for accessing and serving
the Windows share, we deliberately open the file before calling nlinks() in
order to have a stable precondition. Trying to depend on the precondition
"file closed" would be fragile, as the file could have been opened very
easily somewhere else in the program.
- Handle 'subset' argument
- Stop returning the null rev from p1 and parents, as in the non-dirstate case
- Order parents as in the non-dirstate case (ascending revs)
The code eventually converts data through sets to ensure unicity:
do it earlier to allow faster __contains__ lookups and avoid
`del l[l.index(x)]` kind of code.
