[PATCH] auto rename: best matches and speed improvement UPDATE5

[Matt Mackall]

On Fri, 2008-08-22 at 14:47 +0200, Herbert Griebel wrote:
> # HG changeset patch
> # User Herbert Griebel <herbertg at gmx.at>
> # Date 1219406896 -7200
> # Node ID b1173917f68067703012f27c45fd4453926ebd8c
> # Parent  6dcbe191a9b51799a4cd40bd398e826bcd9b4dac
> auto rename: best matches and speed improvements

You've got too much all in one patch. There are three problems with
this. First, the probability of a patch being acceptable is the
-product- of the probability of each individual feature being
acceptable. Which means it's a good idea to submit each feature
separately.

Second, the probability of there being a bug in the patch is the sum of
there being a bug in each feature. Which means you want each feature in
a separate commit for locating regressions.

Third, the difficulty of reviewing a patch increases more than linearly
with the number of features included. Which means we really don't want
to review patches with more than one feature.

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

> The current
> checked file is displayed to give the user feedback about the
> progress.

That's another. Not sure I want this - Mercurial commands are quite
quiet by default.

>  The result is displayed as before but renamed files are
> listed with descending similarity and are no more listed in the added
> and removed list.

That's another. Not sure about this yet either.

> Added files with the same similarity for a removed file are also
> matched against the pathname so directory structure can be preserved
> with regard to renaming identical files in multiple directories.

Huh?

> The options --filters and --sizechange have been added to give the user
> more control over renaming and/or to make it faster.

And that's another.

-- 
Mathematics is the supreme nostalgia of our time.