Update fails with long file name

[Benjamin Fritz]

On Tue, Sep 29, 2015 at 1:43 AM, Adrian Buehlmann <adrian at cadifra.com>
wrote:
>
> It's not impractical. It would be impractical being blamed for creating
> files, which even Windows Explorer can't delete any more.
>
> Think of a user X calling support: "Help! I've cloned this repo from the
> internet, now I even can't delete it any more!".
>

SVN seems to handle it fine. I guess I haven't tried deleting the file from
Windows explorer yet.

> Your repository is not unusable. Just the revision(s) which contain file
> names which violate the Windows naming conventions.
>

That would be almost every revision. So while *technically* correct, that
statement is pedantic at best. It's the equivalent of "Your car isn't
useless, it works fine as long as you don't go at any speed below 10MPH or
above 15MPH."

Now, if I could omit certain *folders* on an update...

Hmm, maybe I can, since I'm actually trying to clone an SVN repository with
hgsubversion. I'll try that later.

> You could, for example, clone this repository to a Linux box, rename
> that file to something which conforms to the Windows naming conventions,
> commit that there, pull that revision to your Windows box and update to
it.
>

Maybe on Linux Mercurial should warn on committing a file name that reaches
this limit, then. It wouldn't help in my case since the file came from a
different version control system, but it could help in some cases.

> As long as you don't update to any offending revisions, you can use that
> repository perfectly fine on Windows. This is includes creating clones,
> exploring the history of the repo, etc.
>

And that's where the annoyance becomes a problem. Can update ever grow a
"--force" option that lets you continue if there is an error in one file,
subrepository, etc.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150929/60b0e06a/attachment-0002.html>