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

[Angel Ezquerra]

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:
>>
>> Hi,
>>
>> When you have subrepos on your repository, running pull on the top
>> repository does not pull changes from its subrepos. Instead subrepos
>> are pulled "as needed" when you update to the corresponding parent
>> repository revisions.
>>
>> This causes a problem if you ever pull from a non default path,
>> because hg update uses the defautl path when pulling subrepos. As far
>> as I know there is no way to tell hg update to use a different pull
>> source,
>
>
> There is - see http://mercurial.selenic.com/wiki/Subrepository#Update .

Perhaps I'm picking on words here but what I meant is that there is no
way to tell mercurial to pull all subrepos on pull, without updating
to tip.

>> nor to tell hg pull to pull all subrepos.
>
> See the advice in http://mercurial.selenic.com/wiki/Subrepository#Pull and
> always use --update.

This is hardly ideal for many reasons:

- You may not want to update to to tip, perhaps because your working
copy is dirty. Yet you may still want to have a look at the new
revisions including changes to subrepos.

- There is a reason why pull and update are separate commands. IMHO it
is a bad idea to always use hg pull --update. Better advice could be
to use hg pull --update if a subrepo has been modified. However, then
you would first need to use hg incoming, check if a subrepo has been
modified, and if it has been, use hg pull --update. This is hardly a
simple workflow.

- If you forget to use --update, there is no easy way to fix your
mistake. You must either use strip and run hg pull again with the
--update flag or you must get into each subrepo and pull it manually.

- When using TortoiseHg, it is not easy to tell mercurial to add the
--update flag. You can do it but it requires a few clicks to do so. I
don't see how we could improve TortoiseHg to make it easier to enable
this flag _occasionally_.


> The best solution is of course to not use subrepos.

That is not always an option, particularly if you are already using
them. Converting a subrepo into a regular folder is basically
impossible unless you move the subrepo contents into a different
folder.

Also, I don't understand why subrepos get such a bad rap around here
("feature of last resort", etc). In my opinion the problem with
subrepos is not with the concept itself, but with the tool that we use
to interact with them (i.e. mercurial!), which is unfortunately not as
mature as it could be in this regard (and this is such a rare thing
that it makes it even more painful).

So my proposal would be to add a --subrepos flag to pull. I can
imagine two possible behaviors for this flag:

1. Pull _all_ subrepos, even if the parent repo has no changes:
    - Pros: Simple and easy to understand
    - Cons: Expensive if you have many subrepos.
2. Pull then check which repos have been modified (e.g. by looking at
the changes to the hgsubstate on the new revisions), then pull from
those
    - Pros: Much more efficient, since only modified subrepos would be pulled.
    - Cons: Could not be used to fix a situation such as the one I described

I like option 2 because it would be the most efficient. It would then
be feasible to tell people to always use the --subrepos when using
subrepos, rather than using --update. Even for GUI users, they could
set this option once on their repos and be done with it.

Does this seem like a good plan?

Cheers,

Angel