The existing help only walked through an example.
Now we first explain the basic rules and then show an example.
The 'collections' example and description only cause confusion and is removed.
Bikeshedded by Patrick Mezard <patrick@mezard.eu>
Fixes (on Windows in cmd.exe):
$ hg -R v:\x\a status V:\x\a\bar
abort: V:\x\a\bar not under root
where v:\x\a is a valid repository with a checked-out file "bar"
(Note the difference in casing: "v:\" versus "V:\")
Changeset ebc9c501f13c introduced a 'root' path component to look for
hgrc files, which is used both as an absolute path and a path relative
to the <install-root>.
The latter one was broken since 'root' was set to an absolute location
and the subsequent os.path.join discarded the <install-root> path prefix.
This improves the performance of "hg log -l1" from 0.21 seconds to
0.07 on a Linux kernel tree.
Ideally we could use xrange instead of range on the most common
path, and thus avoid a ton of allocation, but xrange doesn't support
slice-based indexing.
This patch contains support for Plan 9 from Bell Labs. A README is
provided in contrib/plan9 which describes the port in greater detail.
A new extension is also provided named factotum which permits the
factotum(4) authentication agent to provide credentials for HTTP
repositories. This extension is also applicable to other POSIX
platforms which make use of Plan 9 from User Space (aka plan9ports).
New users of filecache use different names for the function used to compute
the runtime path of the cached file.
Users should subclass filecache and provide their own version of this
function to call the appropriate join function on 'obj' (an instance
of the class that its member function was decorated).
On platforms not supporting shell expansion, scmutil.match() performs glob
expansion on 'pats' arguments. But _matchfiles() revset calls match.match()
directly, bypassing this behaviour. To avoid duplicating scmutil.match(), a
secondary scmutil.matchandpats() is introduced returning both the match object
and the expanded inputs. Note the expanded pats are also needed in the fast
path, and will be used by --follow code path.
When assigning a new object to filecached properties, the cached object that
was kept in the _filecache map was still holding the old object.
By implementing __set__, we track these changes too and update the cached
copy as well.
pathauditor is invoked not only for localpath form using "os.sep" as
separator, but also for normalized form using "/": for example, hg
internal path like "store/data" under ".hg", or ones normalized by
match object
this causes insufficient repository nesting check, because current
pathauditor implementation divides specified path into components by
"os.sep", and this causes to treat multiple path components joined by
"/" as single one on Windows environment.
this patch applies "util.localpath()" on specified path to force it to
be divided into components correctly.
in fact, root for pathauditor also uses multiple path separator on
Windows. but this does not affect audit itself, so "util.localpath()"
is not applied on it.
in current pathauditor implementation, un-normcase()-ed path is
stored into and compared with audit result cache.
this is not efficiency on case insensitive filesystem.
Some character sets, cp932 (known as Shift-JIS for Japanese) for
example, use 0x41('A') - 0x5A('Z') and 0x61('a') - 0x7A('z') as second
or later character.
In such character set, case collision checking recognizes different
files as CASEFOLDED same file, if filenames are treated as byte
sequence.
win32mbcs extension is not appropriate to handle this problem, because
this problem can occur on other than Windows platform only if
problematic character set is used.
Callers of util.checkcase() use known ASCII filenames as last
component of path, and string.lower() is not applied to directory part
of path. So, util.checkcase() is kept intact, even though it applies
string.lower() to filenames.
The most appropriate context is not always clearly defined. The obvious cases:
For working directory commands, we use None
For commands (eg annotate) with single revs, we use that revision
The less obvious cases:
For commands (eg status, diff) with a pair of revs, we use the second revision
For commands that take a range (like log), we use None
The idea is being able to associate a file with a property, and watch
that file stat info for modifications when we decide it's important for it to
be up-to-date. Once it changes, we recreate the object.
On filesystems that can't uniquely identify a file, we always recreate.
As a consequence, localrepo.invalidate() will become much less expensive in the
case where nothing changed on-disk.
