phases and subrepos

[Angel Ezquerra]

On Fri, Feb 3, 2012 at 11:00 AM, Pierre-Yves David
<pierre-yves.david at logilab.fr> wrote:
> On Fri, Feb 03, 2012 at 08:44:42AM +0100, Angel Ezquerra Moreu wrote:
>> Hi,
>>
>> I've been thinking about the interaction between subrepos and phases.
>>
>> One thing that has occurred to me is that there is as common case
>> where rewriting history causes problems, which is when you try to
>> rewrite the history of a subrepo.
>>
>> So, wouldn't it make sense to consider the selection of a subrepo
>> revision on its parent repo a publishing event? That is, committing a
>> change to the hgsubstate file on a parent repo should automatically
>> change the phase of the corresponding subrepo revision (and its
>> ancestors) to public.
>>
>> This would make it really hard to mess up your parent repo by
>> modifying one of its subrepos (with mq, for example).
>>
>> What do you guys think?
>
> I think we better fix subrepo than mark s immutable changeset that have no real
> reason to be immutable (other than rewriting extensions does not handle
> subrepo)
>
>
> --
> Pierre-Yves David

The thing is, how would we fix the subrepos? The problem is that the
parent repo-subrepo relationship is asymmetric, in the sense that the
parent repo is aware of the subrepo, but the subrepo is not aware of
its parent repo. This is a very basic assumption that I doubt will
ever change. Because of this, how can mercurial know that modifying a
draft revision in a subrepo (e.g. using mq from within the subrepo)
will break the parent repo, of which it is totally unaware? IMHO the
only solution is to have mercurial change the subrepo revision phases
as needed when updating the .hgsubstate file.

Even if we "fixed subrepos" as you say, if a revision in the parent
repo is marked as public, then the corresponding subrepo revisions
should be marked as public as well. If the parent repo revision is
immutable, the subrepo history it depends on must be immutable as
well. It does not make sense to have immutable parent repo revisions
depending on draft or secret subrepo revisions.

A trickier case is when a parent repo revision is still in its draft
or its secret phase. Theoretically it could be possible to edit the
subrepo history and then update the parent repo's .hgsubstate file to
reflect that change. But doing so automatically... well, it seems hard
and complex. If a user wants to do it manually, it'd be safer to have
them move the subrepo revision back to draft to prove that they really
know what they are doing.

Angel