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

[Matt Harbison]

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.

[snip]

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

I've never understood the build system argument either.  I'm probably missing
something, but that seems counter to the reasoning [1] for requiring a -S when
committing a repo with dirty subrepos- i.e. preserving a snapshot of the entire
directory structure.  The build system route sounds like instead you commit a
bunch of repos and then let the build system stage them.  Can anyone give a
thumbnail sketch of how they used a build system instead of subrepos?

--Matt

[1] http://www.selenic.com/pipermail/mercurial-devel/2011-October/034816.html