Windows long path experimenting report

Adrian Buehlmann adrian at cadifra.com
Sat Jun 21 06:10:50 CDT 2008


On 21.06.2008 11:40, Paul Moore wrote:
> 2008/6/21 Adrian Buehlmann <adrian at cadifra.com>:
>> As such, I don't understand why Paul (in another post) wants to have that
>> "watermark" magic number at MAX_PATH - I assume this is 256 (Quote: "Basically,
>> I'm against enforcing a limit other than MAX_PATH").
> [...]
>> Or did I misunderstand/confuse something?
> 
> You just missed a bit of context - that wasn't in relation  to Matt's
> adaptive proposal, but to an earlier proposal which (if I understood
> it correctly) would have aborted. But there have been a lot of
> variants and I'm losing track too...
> 
> To be clear - I like the adaptive proposal, and I agree that some
> headroom (for *total* (.hg-relative) path length) makes sense.

What I don't understand here is the term "adaptive". Do you mean
to adapt the threshold?

In http://selenic.com/pipermail/mercurial-devel/2008-June/006800.html
Matt voiced for a *fixed* threshold and for using a better tuned path
transformation function - the "hybrid scheme" - which looks like the best
switched-case path transformation currently.

So, what we currently have is:

A)
* Switch path transformation functions at a threshold (idea parren)
* Use mpm's hybrid hash-transformation for the switched case
* Use a fixed threshold value for all repos on all platforms (mpm)

compared to:

B)
* use long paths on Windows (\\?\.. + win32file.xxxxW functions)

B means some headaches with explorer and e.g. winzip (which can be
circumvented by using robocopy + hg destroy + hg bundle for backup).

A means some performance loss when paths exceed the threshold.

So we can trade performance (B) for ease of use (A).

At least my tests have demonstrated that B) is technically possible.
But the decision itself must be made by Matt anyway.

I can continue to experiment on the detailed implementation of B
if it helps to make a decision.

Maybe I will continue by hacking up some sort of "hg destroy". At least this
would help me to get rid of all these difficult to delete directories
that have accumulated on my hard disk during my testing :-)

Maybe others would then try out my patch too, so we could have more
feedback and from others as well about how doing B feels.





More information about the Mercurial-devel mailing list