[PATCH RFC] obsolete: mark unreachable extinct changesets as hidden

Idan Kamara idankk86 at gmail.com
Mon Jul 16 06:00:10 CDT 2012


On Fri, Jul 13, 2012 at 11:37 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:
> # HG changeset patch
> # User Pierre-Yves.David at ens-lyon.org
> # Date 1342192006 -7200
> # Node ID a08309196cf89676b4f611b7384d1256dc1d7f82
> # Parent  de13ccd4ef8d1ed1abc052a57a88b757c17a0594
> obsolete: mark unreachable extinct changesets as hidden
>
> The repo.changelog.hiddenrev set is update with all extinct() changeset
which
> ain't descendants of either:
>
> - the current working copy,
> - a bookmark,
> - a tag.
>
> It's not really possible to make a lazy filling this set. So we fill it
> unconditionally. This will have a noticeable performance impact on simple
> operation. I expect the future changelog filtering to allows such lazy
> computation.
>
> This changeset focus on a simple implementation of that implement the
right
> behavior. A better implementation will be necessary before it's made
available
> to every user.
>
> diff -r de13ccd4ef8d -r a08309196cf8 mercurial/localrepo.py
> --- a/mercurial/localrepo.py    Fri Jul 13 14:38:49 2012 +0200
> +++ b/mercurial/localrepo.py    Fri Jul 13 17:06:46 2012 +0200
> @@ -207,6 +207,29 @@
>              p = os.environ['HG_PENDING']
>              if p.startswith(self.root):
>                  c.readpending('00changelog.i.a')
> +        if self.obsstore:
> +            ### hide extinct changeset that are not accessible by any
mean
> +            # XXX Making this for each changelog creation force complex
graph
> +            # XXX computation this is a bad idea and we should have a
more lazy
> +            # XXX approach here. But this is ok for a first quick and
dirty
> +            # XXX version as used in several other place regarding
obsstore.
> +            # XXX Repo without any obsolete marker won't be impacted
> +            hiddenquery = 'extinct() - ::(. + bookmark() + tagged())'
> +            # The repo need a changelog to run revset. But don't have any
> +            # because this method is meant to provide one. However the
> +            # changelog is already fully parsed and ready to use. We
temporally
> +            # assign it as an attribute to be able to run revset.
 Later, more
> +            # lazy implementation will probably be called after this
step and
> +            # won't suffer from this issue
> +            self.__dict__['changelog'] = c
> +            # Note that the hiddenrevs needs invalidations when
> +            # - a new changesets is added (possible unstable above
extinct)
> +            # - a new obsolete marker is added (possible new extinct
changeset)
> +            c.hiddenrevs.update(self.revs(hiddenquery))
> +            # remove inserted changelog from class attribut to let
storecache
> +            # do it's jobs
> +            if self.__dict__['changelog'] is c:
> +                self.__dict__.pop('changelog')

This is pretty nasty even for a hack.

Since nothing is going to use obsolete in core this version, can't this be
done outside in an extension (in a more sane way through reposetup)?

>          return c
>
>      @storecache('00manifest.i')
> diff -r de13ccd4ef8d -r a08309196cf8 tests/test-obsolete.t
> --- a/tests/test-obsolete.t     Fri Jul 13 14:38:49 2012 +0200
> +++ b/tests/test-obsolete.t     Fri Jul 13 17:06:46 2012 +0200
> @@ -76,23 +76,6 @@
>    |  date:        Thu Jan 01 00:00:00 1970 +0000
>    |  summary:     add new_3_c
>    |
> -  | x  changeset:   4:ca819180edb9
> -  |/   parent:      1:7c3bad9141dc
> -  |    user:        test
> -  |    date:        Thu Jan 01 00:00:00 1970 +0000
> -  |    summary:     add new_2_c
> -  |
> -  | x  changeset:   3:cdbce2fbb163
> -  |/   parent:      1:7c3bad9141dc
> -  |    user:        test
> -  |    date:        Thu Jan 01 00:00:00 1970 +0000
> -  |    summary:     add new_c
> -  |
> -  | x  changeset:   2:245bde4270cd
> -  |/   user:        test
> -  |    date:        Thu Jan 01 00:00:00 1970 +0000
> -  |    summary:     add original_c
> -  |
>    o  changeset:   1:7c3bad9141dc
>    |  user:        test
>    |  date:        Thu Jan 01 00:00:00 1970 +0000
> @@ -115,18 +98,6 @@
>    |  date:        Thu Jan 01 00:00:00 1970 +0000
>    |  summary:     add new_3_c
>    |
> -  | x  changeset:   4:ca819180edb9
> -  |/   parent:      1:7c3bad9141dc
> -  |    user:        test
> -  |    date:        Thu Jan 01 00:00:00 1970 +0000
> -  |    summary:     add new_2_c
> -  |
> -  | x  changeset:   3:cdbce2fbb163
> -  |/   parent:      1:7c3bad9141dc
> -  |    user:        test
> -  |    date:        Thu Jan 01 00:00:00 1970 +0000
> -  |    summary:     add new_c
> -  |
>    | o  changeset:   2:245bde4270cd
>    |/   user:        test
>    |    date:        Thu Jan 01 00:00:00 1970 +0000
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120716/144f795d/attachment.html>


More information about the Mercurial-devel mailing list