Update fails after pulling from a non default path that has modified subrepos

[Angel Ezquerra]

On Sun, Sep 23, 2012 at 1:13 AM, Matt Harbison <matt_harbison at yahoo.com> wrote:
> Angel Ezquerra <angel.ezquerra <at> gmail.com> writes:
>
>>
>>
>>
>> On Sep 21, 2012 2:09 PM, "Mads Kiilerich" <mads <at> kiilerich.com> wrote:
>> >
>> > On 09/21/2012 01:01 PM, Angel Ezquerra wrote:
>> >>
>> >> On Fri, Sep 21, 2012 at 12:08 PM, Mads Kiilerich <mads <at> kiilerich.com>
> wrote:
>> >>>
>> >>> On 09/21/2012 11:04 AM, Angel Ezquerra wrote:
>> >>>>
>
>> > Subrepos live in the working directory. Pull doesn't touch the working
> directory - update does. It is thus conceptually impossible to pull subrepos
> without updating - especially if the subrepo location in the working directory
> already is used by a file or directory in the working directory.
>>
>> >
>> > It could of course be different if subrepos was something else.
>> I don't get that. Once mercurial has pulled the new revisions from the remote
> repo it can access their contents. In particular it can get the revision ids of
> the modified subrepos quite easily. Pulling them does not seem hard. Perhaps I'm
> missing something?
>
> I think what you are asking for has the same problem as bug 3489 [1] and bug
> 2314 [2] (though that is push related).  Both of these seem to require building
> up a list of subrepo dependencies.
>
> I was looking to fix 2314, and my initial thought was if you know what rev of
> the parent repo you want, you can get the .hgsubstate for that rev and push
> each subrepo at the saved rev, which would in turn push its proper subrepos (if
> any).  But consider two cases where you are pushing out a couple of parent revs.
>
> First, if a subrepo was added and then removed in that range of revs, and the
> last outgoing parent rev doesn't reference it, you will miss it.  This is
> probably compounded if the added and removed subrepo is itself under a subrepo.
>
> Second, if subrepo rev 10 is locked in with parent rev 2, but then in parent
> rev 3 you updated the subrepo back to rev 5, you probably need to push subrepo
> rev 10 (or whatever the latest version the parent referenced) to be useful.
>
> Both of these cases seem to imply pushing each subrepo at every rev a parent
> references.  Substitute 'pull' for 'push' above, and I think the same issues
> apply.  Case 2 falls away if you greedily pull the entire subrepo to its tip.
> But it doesn't fix the case where a subrepo is added and deleted within an
> incoming group.

My idea (and I have not looked at the implementation yet) would be to:

- go through the list of new revisions and create a list of revisions
that modify the hgsubstate.
- starting from the latest, check if the corresponding revision exists
on the local subrepo
    - if it does not, pull that revision from that repo

After this process is done for all the new revisions, you should have
all the subrepo revisions that are referenced by the new parent repo
revisions.

An obvious alternative would be just to look for modified repos and
pull everything from them. This would require less pulls but each pull
could be potentially bigger.

> If this feature does go forward, I would think it would also be useful on
> clone.  But there is already a bug [3] requesting different functionality for
> 'clone -S', so that may not be a good option.

Personally, I don't agree with the proposal in that bug report.
Instead it would be much better to extend "hg add" to handle subrepos.

Cheers,

Angel