Update fails with long file name

[Benjamin Fritz]

On Tue, Sep 29, 2015 at 1:26 AM, Steve (Gadget) Barnes <
gadgetsteve at hotmail.com> wrote:
>
>
>
> On 29/09/2015 06:52, Benjamin Fritz wrote:
> >
> >>
> >
> > 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.
> >
>
> Have you actually tried doing a SVN clone, on Windows, of the repository
> in question at a version where that file exists?

Yes. All revisions dating back over a year have that file. I have HEAD on
trunk checked out through SVN right now.

> I would lay odds that
> a) it will fail & b) the file was created and checked in from a Linux
> system

Wrong, and wrong. It succeeds, and everyone at work (where this repository
lives) uses Windows. I'm pretty much the only weirdo who uses a Solaris
server from time to time by choice, and I'm pretty sure I *am* the only one
on my team who actually uses any SVN commands on the server.

> where the maximums for most file systems are 255 characters in a
> file name and 4096 in a path as opposed to the windows limit of 260 for
> the whole path, including drive letter, colon and a concluding 0x00
> byte.  Possibly worse still the Windows API for file handling allows
> paths that are illegal for all the Windows tools by using \\?\ prefix,
> see
>
https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
> for details.
>

I think that's how SVN gets around the issue.

> Since the offending file WILL cause problems in a large number of
> windows tools can I suggest contacting the SVN administrator on the
> system that it is coming from to request that the file be renamed or
> removed both in the current version if it exists and in the SVN history
> via the SVN dump/filter/import process.
>
> If the offending file does not exist in the current SVN repository,
> again quite likely, but only in the history you can still consider using
> hg without the SVN admin but with a partial history by cloning starting
> from the revision that removed the offending file.

Neither is an option. From the file name, and the fact that it is in a
"verification" folder, I'm assuming it is part of a test that verifies
handling of long file names in the project code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150929/119c42d5/attachment-0002.html>