Re: [Monotone-devel] case insensitive file names

[Stephen Leake]

Richard Levitte <address@hidden> writes:

> In message <address@hidden> on Wed, 18 Jun 2008 03:46:25 -0400, Stephen Leake 
> <address@hidden> said:
>
> stephen_leake> There are a couple of issues here.
> stephen_leake> 
> stephen_leake> First, mtn should use a case-insensitive file name
> stephen_leake> compare. More precisely, it should use whatever file
> stephen_leake> name compare the actual file system uses; that may be a
> stephen_leake> case-sensitive NFS on Windows, for example. That would
> stephen_leake> require a standard API for checking file name equality;
> stephen_leake> is there such a thing? Trying to actually create two
> stephen_leake> files and seeing if an error results would work, but
> stephen_leake> probably be too slow.
>
> I don't know about such an API, and either way it wouldn't help you.
> If the files FOO and foo are two different files, I don't see why they
> should be treated the same.  

That's true in general, although in my particular case it was a
renaming, but the file system case insensitivity confused monotone
into thinking there was a conflict.

It doesn't help that half of my machines are case-sensitive file
systems, the other half case-insensitive :(. I attempt to manage that
by requiring all lowercase file names. Sometimes I allow exceptions;
this experience reduces the number of cases where I will allow
exceptions :).

> The issue isn't really with monotone, it's much bigger. You run into
> similar kinds of trouble with ftp.

Right. But mtn must at least be able to deal with it. In this case, I
had to drop the file from one side, then restore it after the update.
Which is why I complained about update.

> stephen_leake> Second, why does 'update' care if some files are
> stephen_leake> missing? They will be restored or not as appropriate by
> stephen_leake> the update anyway. In the current use case, this check
> stephen_leake> just gets in the way. I'll start another thread for
> stephen_leake> that.
>
> No, 'update' doesn't restore files, it merges changes into files that
> exist in the workspace.  If that change is a rename, it needs the
> original file to perform the rename.  If the change is a few added
> lines somewhere, it needs the original file (which might have been
> changed in the workspace as well) to make that change.

Ah. That makes sense. It runs into the issue I raised in conjuction
with sutures and conflict resolution; should update be doing a merge,
or a checkout?

In this instance, it should be doing a merge, so your point is valid.

But even then, it would be convenient if 'update' would do the
'revert' or 'delete' at the right time, instead of forcing the user to
do it. It can decide which to do by assuming the chosen update
revision has the correct state of the file.

-- 
-- Stephe