subrepo grand plan

Patrick Mézard pmezard at
Wed Oct 19 16:59:10 CDT 2011

Le 19/10/11 22:21, Matt Mackall a écrit :
> On Wed, 2011-10-19 at 21:09 +0200, Martin Geisler wrote:
>> Matt Mackall <mpm at> writes:
>>> On Wed, 2011-10-19 at 09:42 +0000, David.Sedlock at wrote:
>>>> commitsubrepos.
>>>> This is the option we wanted Martin to use so we could get consistent
>>>> behavior of commit/status/diff.
>>>> The existence of this option cannot be consistent with your statement
>>>> "We absolutely cannot have a naked 'hg commit' commit everything but
>>>> subrepos."
>>> You haven't been listening carefully enough. There are THREE choices:
>>> 1) the current default behavior
>>>    'a naked commit ... recurses'
>>> 2) Patrick's commitsubrepos=False behavior
>>>    'a naked commit ... aborts if subrepos are modified'
>>> 3) the thing that everyone asks for (commit only the main repo)
>>>    'a naked commit ... commits everything but subrepos'
>> I just realized that there might have been some confusion here!
>> The option I proposed is like *option 2*, not option 3. In other words,
>> it does not allow you to commit the main repo alone. The recursesubrepos
>> does two things:
>> 1) it sets  commitsubrepos = recursesubrepos for commit
>> 2) it sets opts['subrepos'] = recursesubrepos for status and diff
>> That's all -- the goal is to let the user set recursesubrepos=False and
>> get consistency between the commands as in this table:
>>   If ui.recursesubrepos is set to a boolean B, then we have:
>>             | recurses   | recurses
>>             | by default | with --subrepos
>>     --------+------------+----------------
>>     commit: | B          | True
>>     status: | B          | True
>>     diff:   | B          | True
>> The --subrepos flag is new for commit, it lets the user override the
>> recursesubrepos option on the command line when needed.
>> I'm sorry if my explanation was confusing in the original patch:
> Ok, you're right. I managed to misread both your description AND your
> code the last time around. Thanks for having patience with me.
> But I'm still not super-excited about this. Let me lay out some related
> options for comparison:
> a) Work towards having commit/status/diff consistent AND recursive by
> default
> b) Make commitsubrepos False by default
> c) Add your recursesubrepos option, None by default
> My favorite is (a) because all work here is forward progress towards
> having subrepos more uniformly integrated. This will make subrepos
> better for everyone with no config settings needed. I think the big
> hurdle here (getting these three commands consistent +
> add/forget/remove) is really not that hard given the existing groundwork
> you've set in.
> I ought to have done (b) to start with or very early on, but the option
> never occurred to me. Now I frankly think it's half a step backwards.
> It'll solve a big issue for new users (great), but may upset some
> existing users (which usually trumps). Given that we've got four months
> until the next release this could possibly be in, I'd rather see us
> hurry up and do (a).

Another point for (b) is that by minimizing interactions with subrepos, like not diffing subrepos by default, commands remain fast. Even with 2 or 3 subrepos, I am afraid things could get slower if you have to run one svn diff command per subrepo everytime you run hg diff, especially on Windows. I still have a hack to make hgsubversion svnsubrepo use svn bindings if available for status/_wcrevs() calls, which helped with rebase IIRC.

Patrick Mézard

More information about the Mercurial-devel mailing list