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

[Adrian Buehlmann]

On 15.06.2008 00:10, Paul Moore wrote:
> 2008/6/14 Adrian Buehlmann <adrian at cadifra.com>:
>> The requirements you pile here are such that it makes using Mercurial
>> on Windows impossible.
> 
> Hmm, hardly. Mercurial is perfectly usable on Windows right now. There
> are some issues, certainly, but they can be resolved with some effort.
> The issue here is to avoid more repository format changes than are
> necessary. If 2 issues need repo format changes, let's solve them
> together to avoid 2 repo format changes.

"Hmm, hardly. Mercurial is perfectly usable on Windows right now"

This sentence demonstrates that you haven't understood that Mercurial
on Windows currently doesn't fulfill Matts requirement d:

"d) handles stupidly long filenames"

(which I was accused by Matt of having "conveniently deleted" in one of
my replies)

>> 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?
> 
> You can argue the same about reserved filenames. I have never had a
> problem with either. Why is reserved filenames more urgent than long
> paths?

It is not urgent at all. That problem has existed for quite a long
time now. It is just baffling to read that it must be solved by
switching to using unicode api paths, with the consequence that
neither explorer.exe nor e.g. winzip can handle directories containing
for example a file aux.i any more.

You might want to think about why Microsoft specifically requires
to not use reserved names as stated in
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

specifically the following sentence is important here:

"The shell and the file system have different requirements. It is possible
to create a path with the Windows API that the shell user interface cannot
handle."

For those who don't know: the shell is explorer.exe and that's
exactly what we have seen here. And most other Windows tools can't
handle these long paths either, since nearly all of them
use for example the open file dialog, which is an integral
part of the shell and which can't handle these paths.

Again, ignoring problems with explorer.exe is a very bad idea.
Matt is making a big design mistake here, unfortunately.
At least he will have been told here.
It is very disappointing to insist on this bad decision.
An astoundingly bad decision.

>> You have tortured Paul and me about requirements to be able to copy
>> repos around onto ancient file systems (re case folding patches).
> 
> Please don't bring me into this! I have no issues with how Matt
> handled the case folding patches, and in any case I don't think the 2
> cases are comparable.

Oh. Interesting. And who wrote me he wanted to give up on the
case folding patches, going back to using his initial version in private which
did not comply with Matt's requirements? I have no issues with Matt
handling the case folding patches either. His reasoning *there* was
technically perfect as most of the time. It was you that nearly gave up and it
was me who convinced you to not give up and you did a good job.
The resulting code seems good, the only error left I currently see is the plain
wrong change message in revision 33045179d079 ("This is not strictly necessary,
but retaining the path separators minimises misleading test suite failures"),
which Matt suddenly pulled into his main repo without further discussion.

I compared that case folding episode with the problems here, to demonstrate
how Matt insisted on wanting the maximum on all edges and insisted on
being compatible to the utmost. It is baffling to see that suddenly
the shell doesn't count anymore. That contrast in reasoning is what
strikes me.

I'm sorry that I have mentioned you in this thread here like that, Paul.
I see it was a bad idea.

>> 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.
> 
> But 99.9% of projects can live with the current issues with reserved
> filenames as well.

I don't dispute that. But I thought that we were trying to fix bug
http://www.selenic.com/mercurial/bts/issue793 here?

>> 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.
> 
> I think you need to take a step back and calm down. Have a break and
> come back to this with a fresh view.

Well, thanks for your suggestion. I was and am completely calm. I'm just
baffled to read that Matt declared he wants to switch to using the
unicode api paths on Windows.

Anyway, there is no repository layout change needed when going to
use the \\?\.. paths. Also the file io part will technically be able
to write reserved Windows files, I was told here, so per Matt there
is no repo layout change needed to solve issue793 either.
And the reason for doing all this being Matt's requirements about
speed and all that (which I didn't respond to, unfortunately).

Mercurial could have switched to using the \\?\.. paths long ago if it
is that easy as Matt writes. It will be interesting to see what happens
with Mercurial while this of Matt's decisions is implemented.

I won't be part of those doing that. But that's not important anyway.
Since I'm not important here anyway and after all, it's Matt's project.
It's just very disappointing to see this project going in such a
wrong direction.

What a pity.