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

[Mads Kiilerich]

On 02/14/2011 03:52 AM, Aaron Cohen wrote:
> On Sun, Feb 13, 2011 at 9:09 PM, Mads Kiilerich<mads at kiilerich.com>  wrote:
>> I still haven't seen any good subrepo use cases where recursive commit was
>> an advantage. I can only see the benefit of recursive commit (and
>> "invisible" subrepos in general) if subrepos are used as bad workarounds for
>> the lack of narrow and shallow clones in Mercurial. I hope we eventually
>> will get a real and good solution to the need for flexible cloning and don't
>> have to optimize subrepos for that use case.
>
>
> Hmm, we've just converted our subversion repo which was the dreaded
> "lots-of-projects-in-one-repo" into a basically empty top-level hg
> repo with tons of subrepos. Our typical use-case is to commit in the
> top level on commits that cross multiple project.

Why do you use subrepos instead of just one big repo?

Do you really want to use the same commit message in all the subrepos? I 
would say that for example the commit messages for the changeset that 
implements some new library functionality and the changeset that starts 
using it should have very different commit messages - especially if the 
subrepos are shared and also used in other contexts.

> In particular, if you don't commit on the top level, you run into an
> inconvenience of subrepos not being pulled until .hgsubstate changes:

Sure, a subrepo commit isn't effectuated before a reference to it has 
been committed in the outer repo.

You might have a special case if you have an empty outer repo where you 
really don't care about the commit messages.

/Mads