[PATCH 0 of 5] RFC: Implement O(n + m) algorithm for findrenames()

Mads Kiilerich mads at kiilerich.com
Sun Mar 7 11:01:06 CST 2010


David Greenaway wrote, On 03/07/2010 05:12 AM:
> Hi all,
>
> I maintain a mercurial repository that tracks my company's local changes
> to the Linux sources. Attempting to upgrade from Linux 2.6.24 to the
> latest mainline, I tried the following:
>
>      hg update -C linux-2.6.24-mainline
>      rm -rf *
>      tar -xzvf ~/linux-2.6.33.tar.gz
>      hg addremove -s75
>    

So all the files are "renamed" from linux-2.6.24/* to linux-2.6.33/*? 
That makes it a worst case (which indeed should be handled better), but 
it is also a case which Mercurial won't handle efficient in the storage 
anyway (so far), so it would be better to avoid such massive renamings.

Another comment:
How many files are unchanged and indentical in 2.6.24 and 2.6.33? The 
linux code churn is impressive, but I think that very often in similar 
cases many of the files will be moved/renamed but not modified. Would it 
make sense to make a first cheap scan only looking for 100% match? 
Perhaps by using the cheap "len" as a coarse hash value? How much 
improvement will this give in your example?

/Mads


More information about the Mercurial-devel mailing list