We retain the forwards because it helps code be more ignorant of
implementation details, but use forwards instead of our own method
definitions since we don't need any truly custom behavior for now.
I've done this as its own step so that it's easy to see that the
posixpath implementations pass the doctests in this package. In a
future patch I'll just make these pure forwards of the methods so that
things using pathutil can be oblivious to the posix nature of these
functions.
This adds dirname and join functions to pathutil which are explicitly for
handling '/' delimited paths. The implementations are basically copy paste from
python's posix os.path.dirname and os.path.join functions.
Given that this path is going to abort, it seems OK to spend the time to do an
alternate lookup to better inform the user. The path returned by util.pathto()
ends with '/' at least in some cases, so os.path.relpath() is used instead,
which requires python 2.6.
Before this patch, "reporelpath()" uses "rstrip(os.sep)" to trim
"os.sep" at the end of "parent.root" path.
But it doesn't work correctly with some problematic encodings on
Windows, because some multi-byte characters in such encodings contain
'\\' (0x5c) as the tail byte of them.
In such cases, "reporelpath()" leaves unexpected '\\' at the beginning
of the path returned to callers.
"lcalrepository.root" seems not to have tail "os.sep", because it is
always normalized by "os.path.realpath()" in "vfs.__init__()", but in
fact it has tail "os.sep", if it is a root (of the drive): path
normalization trims tail "os.sep" off "/foo/bar/", but doesn't trim
one off "/".
So, just avoiding "rstrip(os.sep)" in "reporelpath()" causes
regression around issue3033 fixed by e3dfde137fa5.
This patch introduces "pathutil.normasprefix" to normalize specified
path in the specific way for problematic encodings without regression
around issue3033.
