scope of extensions enabled locally in the source of cloning

[Matt Mackall]

On Mon, 2012-05-14 at 21:28 +0900, FUJIWARA Katsunori wrote:
> Hi, devels.
> 
> At cloning in the same local filesystem, even if there are any
> extensions enabled locally in clone source, current implementation
> enables all of them also in destination just while cloning history and
> updating of the working directory in it.
> 
> Such temporarily enabled extensions are not enabled in the destination
> repository after cloning, and this may cause unexpected result, if
> some extensions affecting contents of files in the working directory
> are enabled locally in the source: for example, "keyword" and "eol".
> 
> I already confirmed that this can be fixed by patching to the hook
> setup at "repository()" in "mercurial/hg.py".
> 
> But here, I have a question: what should we do while updating of the
> working directory in the destination repository, when we notice that
> any extensions are enabled locally in the source one ?
> 
>   1. enable such extensions also while updating:
> 
>      this keeps current behavior, so no patch is needed :-)
> 
>   2. disable them while updating:
> 
>      simple patching. but this may confuse users by difference of
>      enabled extensions between source and destination repositories.
> 
>   3. enable(or disable) them, and suggest to enable them also in the
>      destination:
> 
>      users can know what they should do in the destination repository.
> 
>      but no matter what extensions are enabled or disabled, users who
>      want to configure them oppositely should re-update the working
>      directory in the destination to get correct contents of files.
> 
>   4. execute cloning, but omit updating (and show warning):
> 
>      because there is no information to know whether users want to
>      enable extensions also in the destination repository or not.
> 
>   5. or any other solutions ?
> 
> I think that (3) and (4) are friendly for users, but I don't have any
> other decisive factors.
> 
> # should it be configurable ?
> 
> In addition to it, repository local configuration files (".hg/hgrc")
> can contain configurations for extensions affecting contents of files
> in the working directory: e.g.: "[keyword]", "[keywordset]" and
> "[keywordmaps]" sections for "keyword", or "[eol]" section for "eol".
> 
> So, even though such extensions are enabled not repository locally,
> lack of repository local configurations in the source of cloning may
> cause unexpected behavior in the destination of cloning.
> 
> Should we check whether repository local configurations affect
> contents of files in the working directory or not ?

This is all probably unintentional. We should probably strictly isolate
secondary repos from the extensions/hooks of the primary repo. It will
probably be easier to address this once Sune resubmits Peter's
peer/localrepo separation patches though.

-- 
Mathematics is the supreme nostalgia of our time.