[PATCH 00 of 13] Cleanup of the purge extension

Alexis S. L. Carvalho alexis at cecm.usp.br
Sun Mar 4 08:38:23 CST 2007


Thus spake Emanuele Aina:
> I've cleaned up the purge extension, hoping in its inclusion in hgext:
>  - it prints now relative pathnames
>  - it uses the mercurial fs walker
>    * dirstate.statwalk() now yields directories too but they are 
>      filtered out in dirstate.stat() so noone else should be affected
>  - it has a testcase
>  - it uses the mercurial i18n module
>  - it is smaller and simpler

I like these patches, since purge.py becomes quite a bit simpler, but I
have a few questions about the statwalk changes (and there're two issues
that I guess could be solved with two additional patches instead of
rebasing everything).  See my other messages.

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).

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. 

I'd really like to put at least some safety net before moving purge.py
to hgext.

Alexis


More information about the Mercurial-devel mailing list