scope of extensions enabled locally in the source of cloning

[FUJIWARA Katsunori]

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 ?

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp