[PATCH 00 of 13] Cleanup of the purge extension
faina.mail at tiscali.it
Sun Mar 4 15:50:06 CST 2007
Alexis S. L. Carvalho preoccupò:
> I'm more worried about what hg purge will do in arguably broken
> filesystems - specifically case-insensitive ones and HFS (or whatever's
> the name of the OS X filesystem).
It should be HFS+. Didn't know about its name mangling behavior... :(
> In these filesystems, you can tell hg to add a file with one name, but
> os.listdir() may return another name.
> For example, on case-insensitive filesystems:
> $ touch Foo
> $ hg add foo
> $ hg status
> A foo
> ? Foo
> If hg purge removes Foo, users will get angry.
> On OS X things get even muddier, since it likes to use normalized
> Unicode in decomposed form (or something like that): if you create a
> file called "é" ("e" with acute accent as a single character), it will
> decompose it into two characters ("e" and a combining acute accent). So
> the return of os.listdir won't match what we have on the dirstate.
> Maybe it'd be enough to refuse to run if statwalk returns some "m"issing
> file, but I'm not completely sure.
Even this is not going to be enough: in your example, doing 'hg purge'
will erroneously delete the unknown "Foo" file, even if it is not
present any missing file. :(
This problem is not strictly related to 'purge' but more general as it
affects also 'status', as it is shown by your example.
The problem could be divided in two:
- detect case-insensitive or name mangling filesystems
we could maybe put a special file in .hg and, at repo object creation,
try to access it with a different name: for example '.hg/Foo-è',
accessed with '.hg/foo-è' and '.hg/Foo-e`' (in unicode)
- normalize the file names
it can be done in the dirstate.__contains__() method, once a
name-mangling fs has been detected
Is this a reasonable approach?
> I'd really like to put at least some safety net before moving purge.py
> to hgext.
What kind of safety net?
Complimenti per l'ottima scelta.
More information about the Mercurial-devel