[PATCH 3 of 4 V2] localrepo: make supported features manageable in each repositories individually

[Matt Harbison]

FUJIWARA Katsunori <foozy <at> lares.dti.ne.jp> writes:

> 
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy <at> lares.dti.ne.jp>
> # Date 1348917084 -32400
> # Node ID b460a0bb2715122cb23f6787f96dd73a70dc3b76
> # Parent  b9c970b1cf86bb02a3126ab25d132eb589d71e69
> localrepo: make supported features manageable in each repositories individually
> 

[snip]

> @@ -1732,6 +1741,14 @@
>          return r
> 
>      def pull(self, remote, heads=None, force=False):
> +        if remote.local():
> +            missing = set(remote.requirements) - self.supported
> +            if missing:
> +                msg = _("any of required features are not"
> +                        " supported in the destination:"
> +                        " %s") % (', '.join(sorted(missing)))
> +                raise util.Abort(msg)
> +
>          # don't open transaction for nothing or you break future useful
>          # rollback call
>          tr = None
> @@ -1828,6 +1845,14 @@
>              we have outgoing changesets but refused to push
>            - other values as described by addchangegroup()
>          '''
> +        if remote.local():
> +            missing = set(self.requirements) - remote.local().supported
> +            if missing:
> +                msg = _("any of required features are not"
> +                        " supported in the destination:"
> +                        " %s") % (', '.join(sorted(missing)))
> +                raise util.Abort(msg)
> +
>          # there are two ways to push to remote repo:
>          #
>          # addchangegroup assumes local user can lock remote

Minor nit: this error message would read a little better if it said:

    "some required features are not supported in the destination"

or drop "some" to be even more clear that what follows is a list of what is
missing, not a full list of what is required.  I think there is one instance of
this message in patch #4 too.

Will this series affect hooks installed by extensions?  I ask because I have a
repo at work with the eol extension enabled (which looks like it installs
hooks) and nested subrepos.  There's an inconsistency with the line endings
used by 'update -C', and I figured it had something to do with the hooks being
inherited from the parent, but I haven't been able to recreate a simple test
case to exhibit the problem.  If hooks are affected, does this series also fix
2904 [1]? 

--Matt

[1] http://bz.selenic.com/show_bug.cgi?id=2904