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

[Mads Kiilerich]

On 02/14/2011 08:55 AM, Patrick Mézard wrote:
> Le 14/02/11 03:09, Mads Kiilerich a écrit :
>>> $ hg --config ui.commitsubs=no ci -m msg abort: uncommitted changes
>>> in subrepo sub
>>
>> +1
>>
>> We don't use the abbreviation "subs" in other places, so I think
>> "commitsubrepos" would be better even though it is a bit long.
>
> Yes. My only problem with options ending with "subrepo" is I never remember if they are singular or plural :-).

Is it "sub" or "subs"? ;-)

>> But do this setting really belong as a config setting? It is a
>> setting that all users of a given subrepo should agree on, so it
>> seems like it would be better to store it for example in .hgsub .
>
> I disagree with you here, this looks more like a workflow policy than a technical constraint to be enforced at project level. If a coworker never pushes changes breaking subrepos tests because of recursive commits without using this option, fine.

Yes, one of the challenges with subrepos is to use them in a way that 
matches and supports the existing workflows and policies.

But I think "commitsubrepos or not" is more than personal preference.

I will start a slightly different place, with the subrepo structure 
itself. Some users may not need some of the subrepos (or some other 
parts of a repo), but (until we get narrow clones) everybody has to get 
exactly the same clone and working directory. The subrepo structure _is_ 
in a certain way and not subject to personal preferences.

Similarly, it seems to me like there are (two) fundamentally different 
uses of subrepos:

One way is where the separation in subrepos in all ways should be as 
invisible as possible. In this case there must be a workflow policy that 
says that the subrepo boundaries should be ignored, and that all 
operations on the repository should be recursive. There is no reason 
anybody ever should want to make a non-recursive commit. (In this case I 
wonder why subrepos was used in the first place, but I assume it must be 
to work around some other issues. This is apparently the mode Mercurial 
primarily tries to support.)

The other way to use subrepos is where the subrepo boundaries separates 
"modules" that must be considered independently and also might have 
other differences in policies. That allows reuse of modules and 
abstraction of implementation details inside the modules. In this case 
there must be a policy that says that commits in the subrepositories 
must be independent and self-contained. In this case I think it is hard 
to come up with any good use of recursive commit.

The way I see it it is a fundamental property of all subrepos that they 
belong to one of these categories, and the sane value of 
"commitsubrepos" follows from that.

If you have svn subrepos that also are used in other contexts (for 
example with tests) then I would say you are in the latter category 
where there _is_ a fundamental difference in policy. There might be some 
cases where the same commit message can be used in both repos, but I 
think that will be the exception.

It seems to me like the problem most users wants to solve with Mercurial 
subrepo is to separate repositories where there already is a natural 
separation of code. I think this is the problem we should try to become 
better at solving with Mercurial subrepos.

/Mads