Update fails with long file name
Benjamin Fritz
fritzophrenic at gmail.com
Tue Sep 29 22:07:37 UTC 2015
On Tue, Sep 29, 2015 at 4:34 PM, Aaron Cohen <aaron at assonance.org> wrote:
>>
>> I think the clone or pull by itself is not aborted - just the update
>> step. Because it tries to update to a revision containing a reserved
>> filename.
>>
>> [1] https://www.selenic.com/mercurial/hgrc.5.html#ui
>
> I'm not sure what best way to improve the situation is, I see two options:
>
>
> 1) Checkout the file with a warning to some alternate non-reserved name
so something like:
>
> > hg clone test.bundle test
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files
> updating to branch default
> warning: filename contains 'aux', which is reserved on Windows: renamed
to '!aux'
>
> Disadvantages:
>
> a) Breaks the build if anything depended on "aux" to actually have the
right name.
> b) I fear reverse-mapping changes to the "!aux" file so that they end up
committed in the right place wouldn't be entirely trivil
>
>
> 2) Use the "\\.\aux" api to actually create the file. I think this option
is just asking for pain and misery.
>
>
>
> As I've never received a request from anyone concerned that they can't
check out a file with a reserved name, I'm not especially eager to take
this up at the moment.
What about using the "portablefilenames" ui option mentioned above as an "I
know what I'm doing, let me create weird files" flag? Then instead of
always aborting in Windows, it would abort by default, or warn if that
option is set to warn, or ignore if that option is set to ignore?
::> echo hello>\\?\%CD%\aux
::> hg add
adding aux
abort: filename contains 'aux', which is reserved on Windows: 'aux'
::> echo [ui]>.hg\hgrc
::> echo portablefilenames = warn>>.hg\hgrc
::> hg add
adding aux
warning: filename contains 'aux', which is reserved on Windows: 'aux'
Honestly I don't personally care about reserved names, just long ones.
Since Aaron's plugin fixes long file names, and it appears to be a separate
issue I don't particularly care about what Mercurial does with reserved
names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150929/41be6e85/attachment-0002.html>
More information about the Mercurial
mailing list