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

[Aaron Cohen]

On Mon, Feb 14, 2011 at 9:31 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> 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:
>>>
>>
>> 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?

External factors partially, our IDE can't handle the size of all our
projects combined well, our continuous build server has odd behaviour
when a bunch of hg projects are combined into one repo. Also, the
projects are logically separate, combining them would be bowing to a
technical limitation of hg.

> 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.

I would say we have had both cases, commits where we want to have the
same message across all projects, and some where we have "Create
feature A" and the complementary "Use feature A".

>> 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.

Maybe, that does pretty much describe our status at least.

Thanks,
--Aaron