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

[Didly]

On Sun, Sep 23, 2012 at 12:02 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:
>> >>>>
>
> [snip]
>
>>
>> >> - 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.
>> 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?
>
> I suspect it is because with vanilla repos, you can pull, disconnect from the
> source, and update to any rev without ever contacting the source again.  I've
> heard 'Centralized VCS' in the context of largefiles too without it really
> being explained, but it too has a similar limitation.  That said, it has since
> grown a --all-largefiles for clone and pull, which eliminates the requirement
> to connect to the source if that option is always used.  IIUC, what you are
> proposing seems like a similar option to loosen the 'centralized' tie on
> subrepos.  I've gotten hit with similar problems with a non default path pull,
> so I'm interested in helping improve this somehow, if possible.

Yes, this is exactly what I am proposing. Hopefully I'll get some time
to try to make a patch, which will be easier to discuss.

Cheers,

Angel