phases and subrepos

[Jason Harris]

On Feb 3, 2012, at 12:16 PM, Angel Ezquerra wrote:

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

Well said!

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

Yep. You are right, it doesn't make sense to have an immutable superepo
and a mutable subrepo, ***if*** the superepo has committed the substate.

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


I am not sure exactly how it should work, but fairly clearly there should
be some interaction between phases and subrepos.

Cheers,
   Jason