Update fails with long file name

[Benjamin Fritz]

On Sep 29, 2015 12:30 AM, "Adrian Buehlmann" <adrian at cadifra.com> wrote:
>
> On 2015-09-29 00:35, Benjamin Fritz wrote:
> >
> >
> > On Mon, Sep 28, 2015 at 5:24 PM, Matt Mackall <mpm at selenic.com
> > <mailto:mpm at selenic.com>> wrote:
> >>
> >> On Mon, 2015-09-28 at 16:18 -0500, Benjamin Fritz wrote:
> >> > I'm not sure whether the problem is in Mercurial, or in
hgsubversion, so
> >> > please let me know if this is a bad place to report the issue.
> >> >
> >> > I cloned a SVN repository by creating a new (empty) hg repository,
then
> >> > enabling the hgsubversion extension, and doing "hg pull" with the
> > URL of my
> >> > SVN repository.
> >> >
> >> > I used TortoiseSVN for all of the above, so I don't have the exact
> > command
> >> > line.
> >> >
> >> > The pull worked fine but the update step failed as follows:
> >> >
> >> >
> >
E:\Project_Files\XXX-hg\Verification/XXX_config/Error_Config/XXXXXXXXX/XXXXXXXXXXXXXXXXXX0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678.csv
> >>
> >> Programs that use the standard C interfaces have this limitation in
> >> Windows (including cmd.exe and friends). Mercurial intentionally
remains
> >> in this set so that it doesn't create problematic files that not all
> >> programs (such as del!) can handle.
> >>
> >> We'll fix this after Windows itself (including its core utilities)
> >> finally gets its act together.
> >>
> >
> > I'll take that as a "won't fix" then. Pity. I guess I'm stuck without
> > Mercurial on yet another project :-(
> >
> > Unless of course there is some magical workaround, maybe in hgsubversion
> > or some other extension.
>
> The "magical" workaround is not to update to revisions containing files
> which are "illegal" (that is, have names which don't conform to the
> Windows naming conventions [1]) when running on Windows.
>
> The pity is Windows, not Mercurial.
>
> As you have noticed, Mercurial can deal with such names in the
> repository _history_ (that is, inside .hg), even on Windows (which was a
> real PITA to implement...). This includes names which are longer than
> MAX_PATH.
>
> We just decided to refuse creating such illegal names (in the workspace)
> until really basic tools like Windows Explorer are able to handle
> "illegal files" themselves. For example, (silly) Windows Explorer on
> Windows 7 (which is still in widespread use) can't even delete a file
> named AUX. Apparently, this hasn't changed in Windows 10.
>
> [1]
>
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

Seeing as Subversion can handle this file just fine, your explanation may
be completely correct but is also condescending, pedantic, and impractical.
Mercurial *could* support such files. It chooses not to. And because hg
update does not allow ignoring errors of any kind, this makes the entire
repository unusable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150929/3de4cc77/attachment-0002.html>