[PATCH] status: add option to show status of files in subrepos

Steve Losh steve at stevelosh.com
Thu Jul 8 10:20:32 CDT 2010

On Jul 8, 2010, at 11:07 AM, Didly Bom wrote:

> On Thu, Jul 8, 2010 at 4:43 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2010-07-08 at 15:58 +0200, Didly Bom wrote:
> > On Thu, Jul 8, 2010 at 3:44 PM, Matt Mackall <mpm at selenic.com> wrote:
> >         On Thu, 2010-07-08 at 15:24 +0200, Didly Bom wrote:
> >
> >         > What about hg pull/push? As far as I know pull and push do
> >         not
> >         > currently work recursively, do they?
> >
> >
> >         Push does, pull is delayed until update time. See the list
> >         archives for
> >         rationale.
> >
> >
> > Matt, I found the following quote from you:
> >
> >
> > "We don't even know what subrepos to pull until update has occurred
> > because the relevant data is stored in the target changeset."
> >
> >
> > If that is what you refer to, I don't quite understand it. When you
> > pull you simply get new revisions from the source repository, but you
> > do not change the current revision unless you later do an update.
> > Thus, when you do the pull, don't you already know which subrepos are
> > currently (as in the current top repository revision) are included in
> > the top repository? Thus, don't you already know the list of subrepos,
> > for which you could then execute a pull?
> >
> >
> > I don't really understand what has "update" to do with it at all.
> > Would you care to explain it further?
> The information about which subrepo to pull is stored in a file
> called .hgsub.
> There may be many versions of that file pointing to different subrepos
> in different places in many heads of many branches in the repository
> you're pulling/cloning. We won't know which .hgsub version is of
> interest until you decide to update.
> Further, we won't have anywhere to PUT those subrepos until an update
> anyway, because subrepos live in the working directory.
> Matt,
> Thank you for trying to explain this to me. I think that I understand what you are saying. However, what I do not understand is the following:
> - Assume that the user has cloned a repository that contains several subrepos.
> - The user has then used "hg update" at least once, to  select a revision to which its working copy will point to.
> At this point, there is one and only one "current" .hgsub file. This file contains the list of the subrepositories that are referenced by the current revision of repository and to which folders they correspond to. It also says their corresponding "pull sources" (for lack of a better name).
> Now, if the user executed "hg pull", wouldn't mercurial have all the information that it needs to perform the pull on all the subrepositories that are defined for the current revision of the top repository?

It should never need to pull at this point.

When you run 'hg update REV' Mercurial clones/updates the subrepos to the revisions specified in the .hgsubstate file in REV.

When you run "hg pull" after that the .hgsubstate isn't touched (unless you're using "-u", but that's beside the point), so the revisions listed for each subrepo haven't changed, so it doesn't need to pull.

> Obviously, if the user were to update the top repository to another revision, the whole subrespository list could have completely have changed, and a new pull on each subrespository may be needed. Mercurial may even need to remove some subrepos which are not longer included in the new selected revision of the top repository.
> Sorry if this seems obvious to you...
> Angel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100708/df55ce3b/attachment.htm>

More information about the Mercurial-devel mailing list