[PATCH] localrepo: abort commit if a subrepo is modified and ui.commitsubs=no

[Patrick Mézard]

Le 15/02/11 06:40, Kevin Bullock a écrit :
> On 14 Feb 2011, at 8:02 PM, Mads Kiilerich wrote:
> 
>> Kevin Bullock wrote, On 02/14/2011 08:31 PM:
>>> On Feb 14, 2011, at 9:34 AM, Mads Kiilerich wrote: I think it
>>> would be confusing and frustrating to more users to embed this
>>> toggle into .hgsub than in a config setting (particularly if said
>>> config setting was commitsubrepos=False by default).
>> 
>> Why do you think that? Do you have some good use cases where some
>> users are free to commit recursively without considering the
>> subrepo structure, while other users consider the structure and
>> carefully creates commit messages that reflects what actually is
>> changed in the commit?
> 
> 
> I can easily see cases where the desired usage would vary not just
> from user to user, but from commit to commit. Maybe you have a large
> web application structured as a bunch of plugins, so that
> functionality you write for one site can be reused in another. As
> you're developing one feature of the main app you're also developing
> a plugin's functionality, so you want to do recursive commits. But
> later, when that plugin is solid and being used in several projects,
> or once the main app is mature, you'd rather it _not_ do recursive
> commits. If it's a config setting, you can change it per-repo.
> 
> Or say you're doing code review for your colleague who's developing
> said web application. She wants recursive commits, but you're just
> doing some cleanup and so want to limit your commits to the
> particular subrepo. The two of you want a different setting for that
> knob.
> 
> For me the fundamental issue is still this: the way I make the
> warrant that a commit means is my own business, not the subrepo's.
> Mercurial tends to shy away from building policy into the structure
> of a repository—it prefers to provide certain provable guarantees,
> and leave policy to humans—and I don't see why this should be an
> exception.

I do not really buy these arguments but I still agree with the conclusion: this should not be in .hgsub.

1- My gut feeling is we stick with putting data in the repository, not configuration entries driving Mercurial behaviour. We managed to do that until now and while it makes people whine for they cannot deploy policies with repositories, it has the advantage of keeping a pure data model which is great to interoperate. I have a selfish example: say we write this in .hgsub, where do I store this information when I roundtrip with svn using hgsubversion? (which makes the whole idea useless to me).

2- I think the current default is wrong and makes it harder to discuss this issue. Imagine the default were "commitsubrepos=no", I and Mads would be happy, Aaron wouldn't but we would be able to say something like: "the default is safe, if you want to take the risk to commit all kind of stuff automatically, you can just put commitsubrepos=yes in your .hg/hgrc or .hgrc but that's up to you and your conscience". Unfortunately, unless Matt suddenly decides to trample his backward compatibility principles, this is not going to change :-). And after saying this, I feel Mads primary reason to push this into .hgsub is a subtle way to make it the default in his/my own world (which would be great but...)

--
Patrick Mézard