Windows long path experimenting report

[Peter Arrenbrecht]

On Fri, Jun 20, 2008 at 9:00 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 2008/6/20 Peter Arrenbrecht <peter.arrenbrecht at gmail.com>:
>>> Hmm, rather than do this, I'd suggest allowing for up to MAX_PATH
>>> (maybe MAX_PATH-3, see below) and leave it up to the user (with a
>>> suitable warning, if Mercurial hits a problem) to locate the
>>> repository appropriately. (MAX_PATH-3 ensures that putting the repo at
>>> C:\ will always work).
>>
>> Would have to be MAX_PATH-len('C:\name-of-the repo\.hg\store'), no?
>> What's particularly relevant here is the unknown
>> len('name-of-the-repo'). So I'm not sure it is a good idea to approach
>> MAX_PATH too closely.
>
> There's all sorts of games you can play, if necessary, to shorten
> absolute pathnames - use junctions (symbolic links) to point to a deep
> directory from higher up in the filesystem, or use SUBST to point a
> drive letter at a directory. The point here is that the directories
> *above* the repo root are under the user's control - and the user can
> address issues, up to the point (with subst) of putting the repository
> at a "drive root". It's messy, certainly, but in my view, it's better
> than stopping me creating a repository in C:\HG just because someone
> else might want to put it in C:\some\very\long\directory\name\HG.
>
> Basically, I'm against enforcing a limit other than MAX_PATH. We may
> not be able to avoid limiting to MAX_PATH, but let's not make things
> worse. That may mean that some repos can only be checked out into
> suitably shallow locations in the filesystem, but that's OK with me.

Agreed about not enforcing an unnecessary limit. My proposal is that
Windows should *by default* use a compromise such as MAX_PATH/2, which
I expect to work well in most cases, without needing advanced
techniques such as the ones you mention. But you would always be free
to specify the desired limit explicitly during clone, if you have
reason to tweak it.

-parren