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