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

Benoit Boissinot benoit.boissinot at ens-lyon.org
Sun Mar 7 12:12:38 CST 2010


On Sun, Mar 07, 2010 at 06:01:06PM +0100, Mads Kiilerich wrote:
> 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?

not modified is already optimized in the current code (sha1 match, which
in most case doesn't even need to retrieve the data from teh filelog,
see fctx.cmp()).

Benoit

-- 
:wq


More information about the Mercurial-devel mailing list