[PATCH 1 of 2] subrepo: look for local pull source first

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Fri, 2011-03-25 at 16:07 +0100, Martin Geisler wrote:
>> # HG changeset patch
>> # User Martin Geisler <mg at aragost.com>
>> # Date 1300989966 -3600
>> # Node ID a8019f68e1463d6b1d5406f5f22d17f9aa8c828c
>> # Parent  e45780ac829283080ad6b5a5e064e59a163c08d6
>> subrepo: look for local pull source first
>> 
>> With this change, a subrepository will always try to find the
>> changesets it needs in a repository relative to the pull source of the
>> top-most parent repository. So if we have
>> 
>>   repo/
>>     sub/
>> 
>> and make a clone with 'hg clone repo clone', then clone/sub will pull
>> in changesets from repo/sub, regardless of what the .hgsub file says.
>
> There's a lot that's weird with this.
>
> Consider how completely different the behavior will be if you manually
> run hg pull in a subrepo vs having the subrepo code do it for you. I
> think this issue by itself is a show-stopper.

It is not really different from what happens today if you do

  $ hg pull --update /foo

today in the top-level repository: relative subrepository paths are
resolved relative to /foo. At the same time the default path in each
subrepository may be completely different so that

  $ cd sub
  $ hg pull

gives a completely different result. In other words, the patch makes

  $ hg clone /foo

behave like

  $ hg init foo
  $ cd foo
  $ hg pull --update /foo

So it makes the "clone == init + pull" rule of thumb a bit more true.

> Consider how completely different this behavior is from non-hg subrepo
> behavior.

It is just an opportunistic optimization -- the source repository
functions as a cache for changesets and we grab them if we can. Git
subrepos could do the same, I guess.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/