Update fails after pulling from a non default path that has modified subrepos
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:
>>> 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
>> 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
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
>> 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
> 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
> 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 ?
More information about the Mercurial-devel