[PATCH STABLE] clone: enable only appropriate extensions in the target repository
foozy at lares.dti.ne.jp
Wed Jun 27 03:20:07 CDT 2012
At Tue, 26 Jun 2012 12:09:12 +0200,
Mads Kiilerich wrote:
> On 26/06/12 11:11, FUJIWARA Katsunori wrote:
> > # this description assumes that fixing is done in
> > # "extensions.extensions()", as you suggested.
> (I don't know if this markup is intended to emphasize or de-emphasize
> the text, so whatever the intention is it doesn't get through to me ;-) )
> > extensions: select extensions only enabled by specified ui configuration
> > Before this patch, operations covering repositories enable
> > extensions unexpectedly. For example:
> > - one enabled locally in the source of local push/clone is also
> > enabled in the destination (one enabled in the destination of
> > pull is enabled in the source)
> > - one enabled locally in the parent or elder siblings of subrepo
> > tree is also enabled in the other
> > This patch checks whether each extensions should be enabled or not
> > for specified ui configuration to list extensions up.
> It could perhaps be said more explicit:
> This patch will make sure that only extensions that are enabled globally
> will be applied to the target repo.
Would "only extensions that are enabled globally" cause
misunderstanding in the subrepo case ? If not, I'll re-write
> That might emphasize a potential problem: What should happen when a repo
> with largefiles enabled in its .hg/hgrc is cloned? It do make sense that
> largefiles has to be enabled for the new target repo ... but as you
> point out it also makes sense that it isn't. There might be a reason
> this isn't a problem - I don't know. It seems like we don't have a test
> case for that scenario - perhaps we should.
> The solution could perhaps be to let clones of repos with largefiles be
> born with a .hg/hgrc with largefiles enabled ... but don't quote me on
> that ;-)
According to the reply of Matt for my past post asking about this
extension configuration problem, we must not enable largefiles in
destination repo of clone, if it is enabled locally in source one.
This is all probably unintentional. We should probably strictly
isolate secondary repos from the extensions/hooks of the primary repo.
I think that clone/push/pull should abort with "requires features
'largefiles'" in such cases.
I'll confirm Mercurial behavior in such case, and add fixing/testing
for it if they don't do so.
[FUJIWARA Katsunori] foozy at lares.dti.ne.jp
More information about the Mercurial-devel