[PATCH] subrepo: look for local pull source first

[Martin Geisler]

Mads Kiilerich <mads at kiilerich.com> writes:

> Martin Geisler wrote, On 03/25/2011 09:36 AM:
>> You ask an awful lot of questions :) -- let me go through them.
>
> I was too lazy to make it short ;-)

Yeah :) I am glad you took the time to look at my patch.

>>> This will effectively change non-trivial relative paths to trivial
>>> paths, right? I'm all for deprecating and discouraging use of
>>> non-trivial and absolute paths, but why should we change the
>>> semantics of them? Why can't people just start using trivial paths?
>> You cannot use trivial 'sub = sub' paths on a service like Bitbucket.
>
> I heard that kiln now supports nested subrepos. Congratulations! That
> means that either bitbucket (and googlecode) or their users has to get
> moving!
>
> It doesn't make sense that we add complexity to Mercurial 1.9 when the
> real solution is that the hosting sites start supporting nested
> subrepos. When they do it properly it will (in principle) work with
> Mercurial since 1.3.

Hmm, well... I don't really see it as that much complexity. The
conceptual change I'm trying to make is to change the .hgsub file from
being the only source of changeset and instead make it a fallback.

A little like how 'hg clone foo bar' also doesn't use the default path
of foo to find the changesets -- that would be absurd! Instead it
actually uses foo itself... :-)

> So ... the real problem you are trying to solve is clone (with update)
> and subrepos. I agree that that is a case that it could make sense to
> optimize. It can already almost be done with a simple "cp -arl", but
> it only works on unix and it is a bit tricky to avoid hardlinks in the
> working directory.

Yes, indeed.

> Why not just focus on cloning the subrepos while cloning, before the
> update kicks in? It could be argued that cloning already is a special
> case, especially when it is local, and it might thus be justified to
> use trivial relative paths no matter what .hgsub says.

I very much agree, cloning is handled as a rather special in the code
already. I was actually surprised when I first saw that localrepo.clone
does not do a clone backed by hardlinks.

So perhaps I muddled everything by attacking this at a too low level
inside subrepo.py instead of handling it in hg.py...

> A lightly tested ugly proof of concept could be:
>
> --- a/mercurial/hg.py
> +++ b/mercurial/hg.py
> @@ -350,6 +350,13 @@
>              dest_repo.ui.setconfig('paths', 'default', abspath)
>
>              if update:
> +                try:
> +                    for p, (a, b, t) in src_repo[None].substate.items():
> +                        if t == 'hg':
> +                            clone(ui, source + '/' + p, dest + '/' + p,
> +                                update=True)
> +                except Exception: pass
> +
>                  if update is not True:
>                      checkout = update
>                      if src_repo.local():
>
> test-subrepo.t shows that it kind of works and has consequences.

I'll give that patch a whirl here...

> It might fail if the source repo isn't at the tip revision and thus
> not necessarily has the subrepos that tip specifies.

That is similar to how the pull works today: it pulls in everything
instead of pulling in the changeset referenced by the .hgsubstate file.

> It would perhaps make sense to consider the exact revisions when
> cloning, but the real update done a few lines later will correct "all"
> mistakes.

Yes, it will make sure that the subrepo has the correct changeset
checkout out and pull it from the real source if necessary.

-- 
Martin Geisler

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