scope of extensions enabled locally in the source of cloning

[Christian Ebert]

* FUJIWARA Katsunori on Monday, May 14, 2012 at 21:28:54 +0900
> 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 ?

Some thoughts from the perspective from the keyword extension:

The extension's design is very much on the defensive side, i.e.
it encourages not to be propagated automatically. The
recommendatation is also to keep the configuration as local as
possible. This is to avoid the risk of inadvertently store
expanded keywords in history. The idea is: enable it when you
really want or need it, and not without thinking.

Also:

1) configuring 1 [keywordmaps] disables all default maps
2) the [keywordmaps] and [keywordset] config sections do nothing
   unless you enable the extension
3) you can enable the extension at any time - if you "forgot" to
   do so immediately: configure it, and run "hg kwexpand".

The main purpose of the extension is to provide versioning
information to collaborators outside of the Mercurial universe or
version control in general. Scenario: disabled locally, but
enabled on a public server from where collaborators obtain files
they are interested in. The extension is an EXtension in the true
sense of the word. Contrary to the eol extension it is not
related to working on the current directory, INside the VCS. It
mainly provides information to OUTsiders.

>From that perspective my main interest would be in a warning when
all of the following conditions apply:

1) the clone _destination_ is local
2) [keyword] filename patterns are configured globally
3) extensions.keyword= is configured globally
where "globally" means: not only in repo/.hgrc

2) is especially unadvisable in my opinion.

But I'm not sure whether it's a good idea to let the keyword
extension be part some general site policy and be accordingly
verbose. It should stay on the fringes. While the formatting of
the $keywords$ is similar to those in cvs or svn, the idea and
the purpose of the extension in Mercurial is rather different.

c
-- 
Wer auf sein Elend tritt, steht höher.
_HÖLDERLIN:  HYPERION_  --->> http://www.blacktrash.org/hyperion