[PATCH] status: add option to show status of files in subrepos
Nicolas Dumazet
nicdumz at gmail.com
Thu Jul 8 19:17:47 CDT 2010
You might still not understand.
Say you friends adds in his clone rev X.
.hgsub is:
nested = http://path/to/a/repo
Then, he commits rev X+1
.hgsub is
nested = http://another/path/to/a/repo
foobar = file://bla/meh
(And I'm lazy and provide you with only two revisions, but you have to
understand, as Matt says, that we can have several heads, several
branches, and thousands of changesets)
You are asking asking if we can pull subrepos when we pull the main
repo. The simple answer is "no".
When you pull the main repo, from a subrepo prespective you "only" get
a lot of new revisions for .hgsub and .hgsubstate
At _pull_ time, we dont know what revisions we will update to in the
main repo. We thus dont know what revision of .hgsub and .hgsubstate
you are interested into.
You want a toplevel pull to clone/pull the subrepos.
* Actually, pull in the main repo does not even know _which_ repo to
pull. Should we clone http://path/to/a/repo ?
http://another/path/to/a/repo ? file://bla/meh ? Two of those? All
three?
* As Matt wrote, subrepos are stored in the working directory. No copy
of the subrepos (for now) lives in .hg; and we just clone them in
./nested and ./foobar when we are asked to fetch the repos. Because of
this reason, pulling subrepos sounds non-trivial.
So maybe the right question to ask would be "hey, but in most
repositories, we will use at most X subrepo sources, where X is a
rather small-ish number. Why dont we completely clone those X subrepos
sources at pull time, in say, .hg/subrepos/ so we can retrieve the
changesets we're interested in, when updating? Or at least provide a
configuration option to let the user pick if we should do it or not?"
I dont know for sure, but I think that the answer to this question is
"because we only want information related to toplevel repo to be
inside .hg".
2010/7/9 Didly <didlybom at gmail.com>:
>
> On Thu, Jul 8, 2010 at 7:54 PM, Steve Borho <steve at borho.org> wrote:
>>
>> On Thu, Jul 8, 2010 at 12:42 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > On Thu, 2010-07-08 at 18:14 +0200, Didly wrote:
>> >>
>> >>
>> >> On Thu, Jul 8, 2010 at 5:20 PM, Steve Losh <steve at stevelosh.com>
>> >> wrote:
>> >>
>> >> > 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.
>> >>
>> >> Steve, thanks for the explanation.
>> >>
>> >> I was confused because according to Matt's explanation I thought that
>> >> he implied that "pull" _cannot_ be recursive. Yet, it seems that you
>> >> guys are saying that "pull" _could_ be recursive, but it does not
>> >> _need_ to be. Is that correct?
>> >
>> > No, it cannot be recursive. Or at least no one has yet been able to
>> > articulate a fully thought-out approach.
>> >
>> > Again: there may be multiple heads. These different heads may point to
>> > -entirely different- sets of subrepos to pull. Further, none of these
>> > may have corresponding directories in the current working directory.
>> >
>> > So again:
>> >
>> > a) we don't know WHAT subrepos to pull at pull time
>> > b) we don't know WHERE to put them if we did
>> >
>> > And there's also:
>> >
>> > c) with some repo types, don't have a pull operation anyway
>> >
>> > But really, it doesn't matter much. Update recursively pulls subrepos if
>> > needed, so the only time you get into trouble is when repos are
>> > available at pull time and not available at update time.
>>
>> I think Angel is asking is for an option like:
>>
>> hg pull --recursive
>>
>> that pulls revisions into the local repo, then pulls all mercurial
>> subrepos that are checked out in the working revision.
>>
>> --recursive would have to exclude options like --update and --rebase
>> to have any meaning. But I can see it being very useful to a lot of
>> work flows.
>
> Yes, that is exactly what I am asking for :-)
>
> I'd like to be able to pull all subrepos which are present in the _current_
> working revision. In that context it does not matter that there may be other
> revisions in which some of the current subrepos may not be present, or on
> different locations or whatever.
>
> It would be ok if Mercurial complained (with a warning for instance) if one
> or more subrepos are of a type that does not support pull.
>
> Angel
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>
--
Nicolas Dumazet — NicDumZ
More information about the Mercurial-devel
mailing list