[PATCH 3 of 5] subrepo: fix hgrc paths section during subrepo pulling

[Saint Germain]

2010/3/15 Edouard Gomez <ed.gomez at free.fr>:

>>>> For my part I would very much like any input/advice about this patch:
>>>> http://www.selenic.com/pipermail/mercurial-devel/2010-
> March/019313.html
>>>> As I personnaly think that it is essential to subrepo management (to
>>>> guarantee that we are in a particular state with no 'dirty' subrepo).
>>>
>>> Should be nice to force a clean state on subrepos too when main is "up
>>> -C"
>>>
>>> However I would prefer to have default behavior to recurse and a "-N"
>>> option for a not recursive behavior.
>>>
>>>
>> Steve Losh (sjl) was (correctly I think) afraid that a "up -C" would
>> carelessly wipe out any changes not commited on the subrepo. So we
>> decided on an additional flag to specify that we _really_ want this
>> behavior and an error message if we just try to use "up -C". However
>> this might be a good idea to indroduce a --subrepo flag which could be
>> also used for any operations that might also operate on subrepo (like
>> "status" for instance, or even "commit").
>>
>> What do you think about it ?
>
> Basically i'd say that subrepositories should not break the
> "atomic" nature of a mercurial repo. I expect a repo, to always
> behave as a whole.
>
> So that would mean for me:
>  - diff, and stat should recurse in subrepos, because the commit operation
>   will validate the whole set of repos as a whole, so reviewing all
>   the contents is normal and expected.
>  - push/pull must recurse into subrepos. Mandatory because if that's not
>   the case, it'd be easy to end up with main repos lacking their
>   dependencies.
>  - "up" should not recurse because i think that's a developper choice
>   to use a specific version of a sub project (implies merge, testing...)
>  - "up -C" should init all subrepos back to their .hgsubstate state.
>   (your patch)
>  - commit should recurse into subrepos whatever their deepness (my patch)
>
> Now it's true that having "up -C" behaving differently from 'up' is hard
> to defend. It just seems more natural to me.
>
> But I think that we will eventually have to add a global option so that
> recursing is on or off, and can be setup by the user using the [defaults]
> hgrc mechanism if the default behavior doesn't match their expectations.
>
> Shaping default behavior being 2 working with subrepos is still better
> than being alone :-) If more users come up, we could start a poll.
>

Ok, I agree with you. So a global option (--subrepo or --recursive ?) is needed.
I don't know how Benoït want to do this ? With a "poll" ?

Regards,