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

Didly didlybom at gmail.com
Fri Mar 25 15:36:57 CDT 2011


On Fri, Mar 25, 2011 at 7:14 PM, Martin Geisler <mg at lazybytes.net> wrote:

> Matt Mackall <mpm at selenic.com> writes:
>
> > On Fri, 2011-03-25 at 17:27 +0100, Martin Geisler wrote:
> >> 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
> >
> > Show is still stopped. Address the point I raised, pleased. It makes
> > absolutely no sense for a manual pull in a subrepo directory to do
> > something completely different BY DEFAULT than what an automatic pull
> > of the same repo via the subrepo code would do BY DEFAULT. That can
> > only cause problems.
>
> That is already the case today: as you know, the .hgsub file is not
> synchronized with the sub/.hg/hgrc file in any way, and so 'hg pull' in
> the subrepository can do very different things compared to the pull
> triggered by 'hg update' in the outer repository.
>
> So I think the consistency you are trying to achieve is not there in the
> first place.
>
> > Pull --update <some arg> is a completely different beast that is
> > explicitly overriding the defaults.
>
> I think it has some value to make
>
>  $ hg clone /foo/bar
>
> behave more like
>
>  $ hg init bar
>  $ cd bar
>  $ hg pull --update /foo/bar
>

That would be so much simpler and straight forward than the current
behavior!

Setting the pull source in the .hgsub file lets you use non hg subrepos,
which great. However I don't think that that is the use case for subrepos.
For mercurial users using mercurial subrepos there is already a way to set a
pull source: the .hgrc file. It is strange that hg does not use it.
Specially since it makes creating local clones of repositories that contain
subrepos very hard if not impossible.

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110325/0d166bdc/attachment.htm>


More information about the Mercurial-devel mailing list