[PATCH] subrepos: abort commit by default if a subrepo is dirty

[Jason Harris]

On Oct 22, 2011, at 5:58 PM, Matt Mackall wrote:

> On Sat, 2011-10-22 at 17:11 -0500, Jason Harris wrote:
>> On Oct 22, 2011, at 4:18 PM, Martin Geisler wrote:
>> 
>>> Jason Harris <jason at jasonfharris.com> writes:
>>> 
>>>> On Oct 21, 2011, at 3:34 AM, Angel Ezquerra wrote:
>>>> 
>>>>> On Fri, Oct 21, 2011 at 9:53 AM, Martin Geisler <mg at aragost.com> wrote:
>>>>>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>>>>>> 
>>>>>>> This may be a dumb question, but will clean but modified subrepos
>>>>>>> (i.e. those were the current revision has been changed) still be
>>>>>>> committed when commitsubrepo is set to False?
>>>>>> 
>>>>>> That's actually a great question... The answer is that subrepos that
>>>>>> have changed revision *will* be committed when commitsubrepos=False.
>>>>>> 
>>>>>> I must admit that I did not expect this, but now that I think about
>>>>>> it, it seems nice: commitsubrepos=False prevents you from
>>>>>> accidentally reusing a top-level commit message in subrepos. But
>>>>>> you're still allowed to arrange the subrepos like you want (update
>>>>>> to new versions) and then make a big top-level commit to bind
>>>>>> everything together.
>>>>>> 
>>>>>> --
>>>>>> Martin Geisler
>>>>> 
>>>>> I'm glad that is the case! In my opinion this is the right behavior.
>>>>> The new behaviour is great because it avoids modifying the subrepos
>>>>> (by creating _new_ commits, often with a nonsensical commit message)
>>>>> unless you explicitly tell mercurial to do so.
>>>>> 
>>>>> But changing the subrepo revision does not modify the subrepo itself.
>>>>> You are basically modifying the .hgsubstate file, which is part of the
>>>>> parent repo.
>>>>> 
>>>>> So in my opinion this makes a lot of sense.
>>>> 
>>>> 
>>>> Is there an option to control this? It would be really nice to turn
>>>> this off in our workflow. If we could then people could still rebase in
>>>> unpushed subrepo's etc, without nuking the repo by accident.
>>> 
>>> I'm not sure what you ask to control. There is indeed an (old) option to
>>> control the recursive behavior of commit and there is a new --subrepos
>>> flag that overrides the option to make commit recurse.
>> 
>> I want an option so that if the subrepos have been changed and committed then
>> committing in the parent repo will *not* change the .hgsubstate.
> 
> This option is better known as "turn off version control fundamentals"
> and has rather dim prospects.
> 
> If project X has subrepo Y that it's not actually tightly coupled to on
> a revision by revision basis, then the right way to do it is to make Y a
> sibling of X (with a new parent W) rather than a child:
> 
> http://mercurial.selenic.com/wiki/Subrepository#Recommendations

Exactly! I want to be able to do exactly the recommended behavior of having
loose coupling but with our current historical layout!

Knowing what we know now, we would have organized things just the way that is
given in recommendations.... But we didn't, since our layout predated those
recommendations.

Maybe we should run convert on the parent repo and strip out the .hgsubstate and
.hgsub, and then go through manually creating a super repository linking the
versions at various states... (Likely we can write a script to automate this...
In fact just to check we aren't reinventing wheels has anyone else written such
a script? Basically to convert a repository with subrepos into a flatter
structure ala the recommendations?)

Still, having such an option which would allow loose coupling just as in the
recommendations, would be quite nice. (And in addition it would allow layout of
the repositories in a way which is convenient for builds, etc. Ie people could
lay the repositories out in whichever way they wanted. Instead of having to lay
them out at the same level and then having to sym-link them into the structure
required for the build, etc.

Cheers,
   Jas