If you pass a Windows short-name as the destination to "svn co" then it
will normally work correctly, unless the short name is actually longer
than the "long name" in which case the string handling seems to go awry.
First a working example:
> mkdir ALongName.impl
> dir /x
...
27/03/2015 12:50 <DIR> ALONGN~1.IMP ALongName.impl
...
>svn co --depth=files http://svn.apache.org/repos/asf/subversion/trunk
ALONGN~1.IMP
A ALongName.impl\NOTICE
A ALongName.impl\get-deps.sh
A ALongName.impl\Makefile.in
A ALongName.impl\LICENSE
A ALongName.impl\build.conf
A ALongName.impl\win-tests.py
A ALongName.impl\COMMITTERS
A ALongName.impl\README
A ALongName.impl\BUGS
A ALongName.impl\configure.ac
A ALongName.impl\TODO
A ALongName.impl\.ycm_extra_conf.py
A ALongName.impl\INSTALL
A ALongName.impl\CHANGES
A ALongName.impl\autogen.sh
A ALongName.impl\gen-make.py
A ALongName.impl\aclocal.m4
U ALongName.impl
Checked out revision 1669571.
That's behaving as expected. SVN checks out into the ALongName.impl
directory, as both the long name and the short name should be
synonymous. It outputs the long name, not the short name given on the
command-line, which was slightly surprising but not a problem.
Presumably the result of some canonicalisation code somewhere.
Now lets try the same sequence of operations with a different directory
name:
> mkdir api.impl
> dir /x
...
27/03/2015 12:52 <DIR> API~1.IMP api.impl
...
>svn co --depth=files http://svn.apache.org/repos/asf/subversion/trunk
API~1.IMP
A api.implP\NOTICE
A api.implP\get-deps.sh
A api.implP\Makefile.in
A api.implP\LICENSE
A api.implP\build.conf
A api.implP\win-tests.py
A api.implP\COMMITTERS
A api.implP\README
A api.implP\BUGS
A api.implP\configure.ac
A api.implP\TODO
A api.implP\.ycm_extra_conf.py
A api.implP\INSTALL
A api.implP\CHANGES
A api.implP\autogen.sh
A api.implP\gen-make.py
A api.implP\aclocal.m4
U api.implP
Checked out revision 1669571.
Here the behaviour is incorrect, it's created a new folder "api.implP"
and checkout out to that. The spurious "P" character is the last
character of the short name, so it looks like a buffer is being
overwritten incorrectly in situations where the long name turns out to
be shorter than the short name. That happens in this case because,
although "api.impl" is short, the "file extension" is more than 3
characters so this isn't a valid Windows 8.3 (short) name.
The use of the --depth=files option isn't signficant here, it just makes
the reproduction steps quicker to run.
I think this is a pretty clear example of a bug, does anyone else agree?
Thanks,
--
Stephen White, CoreFiling Limited
http://www.corefiling.com
Phone: +44-1865-203192
