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

[Kevin Bullock]

On Feb 14, 2011, at 9:34 AM, Mads Kiilerich wrote:

> On 02/14/2011 08:55 AM, Patrick Mézard wrote:
>> Le 14/02/11 03:09, Mads Kiilerich a écrit :
>>> 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.


But in either case, you're still talking about workflow policy, not the fundamental nature of subrepos. If there were really such different technical requirements, there should be two distinctly-handled types of subrepos (say 'modules' and 'externals' or somesuch distinction). 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).

By way of analogy, one common use case for Mercurial repositories is a centralized-repo model: everyone clones from and pushes to the same repository. This is accomplished by workflow policy, and by setting '[paths] default = uri://server/path/to/central/repo' in each clone's .hg/hgrc. But no clone is given a 'fundamental property' of being tied to a centralized repository.

I also don't think the distinction between the two cases is as clear as you've drawn it.

Or from another perspective, a commit is a warrant made by the committer: "this is a snapshot of the entire project in a certain state." How one makes that warrant doesn't matter; whether you do it with a simple recursive commit, or with a manual commit in subrepos and then an outer commit of the whole state, the warrant means the same thing. Therefore it's not a fundamental property of the subrepo structure.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock