Update fails after pulling from a non default path that has modified subrepos
angel.ezquerra at gmail.com
Fri Sep 21 16:44:54 CDT 2012
On Sep 21, 2012 2:09 PM, "Mads Kiilerich" <mads
<mads at kiilerich.com>@<mads at kiilerich.com>
kiilerich.com <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<mads at kiilerich.com>
@ <mads at kiilerich.com>kiilerich.com <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<http://mercurial.selenic.com/wiki/Subrepository#Update>
#Update <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.
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?
>> - 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
Sorry, I don't get that either. As long as you do not use absolute subrepo
paths there is nothing centralized about using subrepos! What do you mean?
>>> 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.
I agree with that :-)
> 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.
But I don't agree with that at all. IMHO subrepos solve a pretty specific
yet useful use case, linking versions of related modules with each other.
Build systems may cover part of this use case but it is not their primary
goal. Also not all programming languages require a "build". Setting up a
build system just to do what subrepos can easily do is overkill.
Mercurial such repos have a few rough edges but I think those can be
improved. The problem that triggered this thread is an example of such
>> 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 <http://mercurial.selenic.com/wiki/OnsubExtension>://<http://mercurial.selenic.com/wiki/OnsubExtension>
Yes, although as I said I think that option #2 (pulling the modified reoos
alone) would be better.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel