phases and subrepos

[Pierre-Yves David]

On Fri, Feb 03, 2012 at 12:16:07PM +0100, 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.

What I see here is that making a revision public should make revision
referenced in .hgsubstate public (a simple extension of phase compatibility
rules)

Moving boundary backward requires a --force option. Okay, People can be in
trouble if they abuse --force option to mutate public changeset. This seem
perfectly fine to me.

There is still no valid semantic reason to make commit *public* by default if
you use subrepo.

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

I Perfectly agree on this point

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

This semantically wrong. If repository rewriting extension does not handle
subrepo properly they should abort. Misusing phase for this purpose would be
and error imho.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120203/e7c51e2b/attachment.pgp>