[PATCH STABLE] largefiles: check wheter specified patterns are related to largefiles strictly
Na'Tosha Bard
natosha at unity3d.com
Wed Feb 15 14:08:38 UTC 2012
2012/2/15 FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # Date 1329314469 -32400
> # Branch stable
> # Node ID c0a0446aaa86e78626b3ae8c9a400320bb140c42
> # Parent f7e0d95d0a0bc5545f3dad40b9ceaee362d7c553
> largefiles: check wheter specified patterns are related to largefiles
> strictly
>
> current 'lfiles_repo.status()' implementation examines whether
> specified patterns are related to largefiles in working directory (not
> to STANDIN) or not by NOT-EMPTY-NESS of below list:
>
> [f for f in match.files() if f in lfdirstate]
>
> but it can not be assumed that all in 'match.files()' are file itself
> exactly, because user may only specify part of path to match whole
> under subdirectories recursively.
>
> above examination will mis-recognize such pattern as 'not related to
> largefiles', and executes normal 'status()' procedure. so, 'hg status'
> shows '?'(unknown) status for largefiles in working directory unexpectedly.
>
> this patch examines relation of pattern to largefiles by applying
> 'match()' on each entries in lfdirstate and checking wheter there is
> no matched entry.
>
> it may increase cost of examination, because it causes of full scan of
> entries in lfdirstate.
>
> so this patch uses normal for-loop instead of list comprehensions, to
> decrease cost when matching is found.
>
Did you do any performance testing before and after this patch? What is
the difference in performance? What sort of repository did you test it on?
Na'Tosha
>
> diff -r f7e0d95d0a0b -r c0a0446aaa86 hgext/largefiles/reposetup.py
> --- a/hgext/largefiles/reposetup.py Fri Feb 10 16:52:32 2012 -0600
> +++ b/hgext/largefiles/reposetup.py Wed Feb 15 23:01:09 2012 +0900
> @@ -118,8 +118,10 @@
> # handle it -- thus gaining a big performance boost.
> lfdirstate = lfutil.openlfdirstate(ui, self)
> if match.files() and not match.anypats():
> - matchedfiles = [f for f in match.files() if f in
> lfdirstate]
> - if not matchedfiles:
> + for f in lfdirstate:
> + if match(f):
> + break
> + else:
> return super(lfiles_repo, self).status(node1,
> node2,
> match, listignored, listclean,
> listunknown, listsubrepos)
> diff -r f7e0d95d0a0b -r c0a0446aaa86 tests/test-largefiles.t
> --- a/tests/test-largefiles.t Fri Feb 10 16:52:32 2012 -0600
> +++ b/tests/test-largefiles.t Wed Feb 15 23:01:09 2012 +0900
> @@ -948,4 +948,50 @@
> $ test -L largelink
> $ cd ..
>
> +test for pattern matching on 'hg status':
> +to boost performance, largefiles checks whether specified patterns are
> +related to largefiles in working directory (NOT to STANDIN) or not.
>
> + $ hg init statusmatch
> + $ cd statusmatch
> +
> + $ mkdir -p a/b/c/d
> + $ echo normal > a/b/c/d/e.normal.txt
> + $ hg add a/b/c/d/e.normal.txt
> + $ echo large > a/b/c/d/e.large.txt
> + $ hg add --large a/b/c/d/e.large.txt
> + $ mkdir -p a/b/c/x
> + $ echo normal > a/b/c/x/y.normal.txt
> + $ hg add a/b/c/x/y.normal.txt
> + $ hg commit -m 'add files'
> + Invoking status precommit hook
> + A a/b/c/d/e.large.txt
> + A a/b/c/d/e.normal.txt
> + A a/b/c/x/y.normal.txt
> +
> +(1) no pattern: no performance boost
> + $ hg status -A
> + C a/b/c/d/e.large.txt
> + C a/b/c/d/e.normal.txt
> + C a/b/c/x/y.normal.txt
> +
> +(2) pattern not related to largefiles: performance boost
> + $ hg status -A a/b/c/x
> + C a/b/c/x/y.normal.txt
> +
> +(3) pattern related to largefiles: no performance boost
> + $ hg status -A a/b/c/d
> + C a/b/c/d/e.large.txt
> + C a/b/c/d/e.normal.txt
> +
> +(4) pattern related to STANDIN (not to largefiles): performance boost
> + $ hg status -A .hglf/a
> + C .hglf/a/b/c/d/e.large.txt
> +
> +(5) mixed case: no performance boost
> + $ hg status -A a/b/c/x a/b/c/d
> + C a/b/c/d/e.large.txt
> + C a/b/c/d/e.normal.txt
> + C a/b/c/x/y.normal.txt
> +
> + $ cd ..
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
--
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies - Copenhagen
*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120215/9a34a1d9/attachment-0002.html>
More information about the Mercurial-devel
mailing list