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

Mads Kiilerich mads at kiilerich.com
Fri Sep 21 07:09:16 CDT 2012


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:
>>> 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.

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.

> - There is a reason why pull and update are separate commands.

Yes, that is a DVCS feature. But subrepos tie them together and 
essentially makes it a Centralized VCS. That is one of the bad things 
about subrepos.

>
>> 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).

My 5 cents:

The "subrepos" problem is a valid use case. But it is essentially a 
build system problem. A solution in the version control system will thus 
never be a good solution unless your version control system grow into a 
build system.

> 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.

Like http://mercurial.selenic.com/wiki/OnsubExtension ?

/Mads


More information about the Mercurial-devel mailing list