Windows people: please help check idea for a new Mercurial repository layout

Adrian Buehlmann adrian at cadifra.com
Sat Jun 14 14:38:33 CDT 2008


On 14.06.2008 20:49, Matt Mackall wrote:
> On Sat, 2008-06-14 at 20:23 +0200, Adrian Buehlmann wrote:
>> On 14.06.2008 18:45, Matt Mackall wrote:
>>> Oh, I'm sure it will confuse the hell out of lots of things. But only
>>> when users have such files in their repo. And only when they use tools
>>> that poke in .hg. And there aren't many good reasons to do that beyond
>>> backup and manual cloning. But really this is just a quick hack.
>> There is no need to do such a "quick hack".
> 
> Oh? What do you propose? You've conveniently deleted the rest of my
> message where I detailed how doing anything else is quite hard.

There is nothing convenient here, indeed. I've deleted it, because
there is not much point in responding to requirements that make
a solution on a platform impossible.

>> And confusing explorer.exe on Windows is a very bad idea.
> 
> Absolutely, granted. But is it worse than not being able to access a
> repo AT ALL because it has path names that are too long? 
> 
> Forget about the reserved filenames issue, it is trivial compared to the
> long paths one.
> 

Well, Matt. You can pile requirements up to the point where there is
no solution any more.

That's what you have done here.

We have lived with the path length limit on Windows for quite some time
now.

Then I made a proposal that would enable cloning of repos containing
tracked paths with Windows reserved names.

You implicitly rejected that proposal, by requesting to solve in the very same
repo layout change that the path length limit be increased as well.

My proposal would have required a repo layout change, yes. So what?

Suddenly, that path length limit must be solved in the same step.
There is absolutely no technical need to do that.

We could even have changed the default repo layout for Windows users
alone (see my last post to mercurial-devel).

The requirements you pile here are such that it makes using Mercurial
on Windows impossible.

Why? Again, we have lived with the path length limit for quite some time
now. Why is that limit suddenly unacceptable anymore, up to the point
that you jump on things like using \\?\.. paths, which are known to
cause severe problems for Windows users?

I really don't get it, Matt.

You have tortured Paul and me about requirements to be able to copy
repos around onto ancient file systems (re case folding patches).

Now we should suddenly applaud to the idea of using unicode api paths?
As a quick hack? To solve what?

It is nice to know that NTFS has a path limit of 32K, yes. I've known
that already. But Windows means Windows XP with explorer.exe and all sorts
of limits.

And there are a whole lot of projects that can live with the current path
length limit. They could even live with the new, a bit smaller
path limit that results if we add a period in front of every path component
in the store, so that we can clone repos containing reserved filenames.
Instead of just hanging forever or doing a silly abort (people would
rightfully have asked: why do they abort if they detect it? Most people
can live with the fact that there is a repo layout change for getting their
work done on a clone on windows - "yeah, I need to upgrade to Mercurial X
because we have that borked repo with an file with a reserved name in it").

There is really absolutely no point in aborting a clone if there is such
a simple path encoding, that would enable storing that very repo on Windows
without using rocket science.

The current state with regards to reserved windows file names originating
from unix repos is a real problem, as you cannot even fix it if a user checks
in an offending file, as deleting it in a later revision won't make
the problem file disappear in the store (besides converting the repo and
invalidating all IDs).

And the technical solution would be simple. If we don't go over board with
requirements we currently don't fulfill, and many users of Mercurial can
live with and have lived with and would be happy to continue to live with.




More information about the Mercurial mailing list