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

Matt Harbison matt_harbison at yahoo.com
Sat Sep 22 18:13:50 CDT 2012

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>
> >>>
> >>> On 09/21/2012 11:04 AM, Angel Ezquerra wrote:
> >>>>

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

I think what you are asking for has the same problem as bug 3489 [1] and bug
2314 [2] (though that is push related).  Both of these seem to require building
up a list of subrepo dependencies.

I was looking to fix 2314, and my initial thought was if you know what rev of
the parent repo you want, you can get the .hgsubstate for that rev and push
each subrepo at the saved rev, which would in turn push its proper subrepos (if
any).  But consider two cases where you are pushing out a couple of parent revs.

First, if a subrepo was added and then removed in that range of revs, and the
last outgoing parent rev doesn't reference it, you will miss it.  This is
probably compounded if the added and removed subrepo is itself under a subrepo.

Second, if subrepo rev 10 is locked in with parent rev 2, but then in parent
rev 3 you updated the subrepo back to rev 5, you probably need to push subrepo
rev 10 (or whatever the latest version the parent referenced) to be useful.

Both of these cases seem to imply pushing each subrepo at every rev a parent
references.  Substitute 'pull' for 'push' above, and I think the same issues
apply.  Case 2 falls away if you greedily pull the entire subrepo to its tip.
But it doesn't fix the case where a subrepo is added and deleted within an
incoming group.

If this feature does go forward, I would think it would also be useful on
clone.  But there is already a bug [3] requesting different functionality for
'clone -S', so that may not be a good option.

All that said, I can see a useful case for this- if I work all week pushing and
pulling to/from the regular repos I use, but then at the end of the week I can
pull everything to a thumb drive and take it home.  I could update, though that
is somewhat of a waste because I don't need a working dir there.  Missing added
and removed subrepos is a bit academic in that case, because I very rarely add
or remove subrepos.


[1] http://bz.selenic.com/show_bug.cgi?id=3489
[2] http://bz.selenic.com/show_bug.cgi?id=2314
[3] http://bz.selenic.com/show_bug.cgi?id=3389

More information about the Mercurial-devel mailing list