[PATCH] auto rename: best matches and speed improvements UPDATE2

[Christian Boos]

Herbert Griebel wrote:
> # HG changeset patch
> # User Herbert Griebel <herbertg at gmx.at>
> # Date 1222956008 -7200
> # Node ID 18c6c172e8ddd37a46c91d7c92fd002046ba4760
> # Parent  f29b674cc2210126c2899d94d882c367a8ea64bc
> auto rename: best matches and speed improvements
>
> The auto rename feature of addremove did not rename to the best match
> and was very slow. The new implementation fixes this using all matches
> and using statistics of the file content to speed up the matching.
> ...
>   

I just had to cancel an `hg addremove -s80' which was taking forever 
(probably hours if I had let it terminate). Then I remembered that patch 
and indeed, with its help, the whole operation succeeded in 1m20s, which 
is quite acceptable given the size of the changeset (5600 additions, 400 
removals - obtained by tracking 3rd party releases).

I see that there were some objections to the patch, notably Matt 
mentioned that the patch needed to be broken in smaller parts. Herbert 
replied that the patch above was actually already the result of the 
request split (http://markmail.org/message/52pxvaxoqwdvzb43):

 > (Matt)
 > > (Herbert)
 > > The auto rename feature of addremove did not rename to the best match
 > > and was very slow. The new implementation fixes this.
 >
 > That's one patch.

i.e. this is what we're talking about if I'm right.
So, is this the status quo? What needs to get done next? I think this 
patch really deserves some attention.

-- Christian