[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