[ANN] caseguard - an extension for case-folding collision prevention

[alexandru]

Thanks for the feedback, please see my comments inline:

On 2010-02-03, at 6:54 PM, Nicolas Dumazet wrote:

> 
> I think that I found a bug, though:
> 
>  touch foo
>  hg add foo
>  touch FoO
>  hg add FoO
> 
> which goes smoothly and should not. There is also the case, which
> might or might not end up use the same codepath once fixed:
> 
>  touch foo FOO
>  hg add

I've pushed a quick fix for the first bug. I have an idea for addressing the second one, but it'll likely arrive sometime tomorrow.

> 
> 
> I'm wondering if it would need be interesting here to add a parameter
> to match objects to enable case-insensitivity?
> 
> If you do so, casecollide gets much simpler, only using high-level API:
> 
>  def casecollide(ui, repo, *pats, **opts):
>      colliding = False
>      m = cmdutil.match(repo, pats, opts, caseinsensitive=True)
>      modified, added, removed, deleted, unknown, ignored, clean =
> repo.status(match=m, unknown=True)
> 
>      matching = dict((f.lower(), f) for f in filelist for filelist in
> (modified, added, clean))
> 
>      # unknown contains the files matched by the add command
>      for file in unknown:
>          key = file.lower()
>          if key in matching:
>              colliding = True
>              # ui.warn(..) using matching[key]
>          else:
>              matching[key] = file
> 
>     return colliding
> 
> Or is it me? Sometimes I have strange ideas, feel free to say if it's
> the case :)

This sounds like it would require changes to core, to add another argument for cmdutil.match? I'm guessing such a change depends on how many others think it would be useful, but for now I'm happy with the less-elegant version of casecollide (though yours does look nice)

> (If you want to prevent badness when the extension is activated on an
> already problematic repository, you will want to check what is
> happening when first building matching)

I think the best approach to that would be to just throw some warnings about what's likely to cause problems. I'd likely do it as a separate command that the user can run explicitly.

Thanks!
—
@