[PATCH 1 of 3] pull: add --subrepos flag

[Angel Ezquerra]

On Wed, Feb 20, 2013 at 6:57 AM, Matt Harbison <matt_harbison at yahoo.com> wrote:
> On Sun, 17 Feb 2013 13:19:16 +0100, Angel Ezquerra wrote:
>
>> # HG changeset patch
>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>> # Date 1360519226 -3600
>> # Node ID abbd26cca35280fb8f784b3f2c02eef71696c47b
>> # Parent  55b9b294b7544a6a144f627f71f4b770907d5a98
>> pull: add --subrepos flag
>>
>> The purpose of this new flag is to ensure that you are able to update to any
>> incoming revision without requiring any network access. The idea is to make sure
>> that the repository is self-contained after doing hg pull --subrepos, as long as
>> it already was self-contained before the pull).
>>
>> When the --subrepos flag is enabled, pull will also pull (or clone) all subrepos
>> that are present on the current revision and those that are referenced by any of
>> the incoming revisions.
>
> I haven't gotten a chance to really play with this yet, so I'm going more off the
> comments here- I apologize if these answers should be obvious, but I'm not familiar
> enough with some of the code.
>
>  - Is there an easy way to tell if the repo is/was self contained?  (Maybe
>    incoming -S?)

No there is not. I don't think incoming -S would do the trick since
that would just tell you if there are _new_ incoming revisions on some
of the _current_ subrepos. A repo is "self-contained" if it is
possible to update to any of its revisions withing requiring a pull of
one or more of its subrepos.

I don't know of any existing mercurial command that would be able to
give you that information.

>  - Is the 'self-contained' bit to limit overhead on each pull, or is there another
>    reason this can't ensure the result is self contained?  'Push' and 'outgoing -S'
>    recognize (almost) everything going in the other direction, so it might be nice
>    to have the same capability with a form of pull.  (I may have found a push bug
>    that I haven't gotten back to yet.)

I'm not sure I understand what you mean. I don't think you (we?) must
give too much importance to this "self-contained" concept. It is just
a way for me to explain the purpose of the patch, and specially to
explain why we must look for subrepos on all the new incoming
revisions, and why we cannot just limit ourselves to pulling the
subrepos on the current revisions (short answer: because new subrepos
may appear on the new, incoming revisions).

My patch explicitly says that hg pull -S will only make your subrepo
self-contained if it was already self-contained before. This is in
order to avoid having to look for subrepos on all the repo history,
rather than just looking for subrepos on the incoming revision (and
the current one).

>  - The full subrepo gets pulled, even revs not committed to the parent?  I think
>    that's a good thing, because regularly get burned when I 'pull -u' the tree to
>    another machine and then go to apply the rest of a patch queue to the subrepo.

Yes. It is perhaps not optimal but I think it is simpler. In addition
if different parent repo revisions point to different revisions on a
subrepo there is no way for us to tell which of those subrepo
revisions is the one that is closes to tip, or which ones are
ancestors of the other ones, etc. As a result we would need to perform
as many pulls on a given repo as the number of different revisions of
that subrepo that were referenced on the parent repo. That is complex
and slow, so it is much simpler and possibly faster (in some cases at
least) to just pull all revisions from each subrepo.

> I'll try to experiment with this some in the next few days.  I ran into issues with
> what I'm working on (push, outgoing) with deeply nested subrepos, and also when a
> parent locks in an earlier subrepo version.  I wonder if deeply nested subrepos will
> be a problem here since hgsubrepo.pull() doesn't walk its subrepos and pull them.

I must confess that I have not tried that too much. We should
definitely do this recursively. That being said I hope to get some
feedback on the current version that I sent to the list first.

Cheers,

Angel