phases and subrepos

[Angel Ezquerra]

On Sat, Feb 4, 2012 at 3:09 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
> On Fri, Feb 03, 2012 at 02:36:55PM +0100, Angel Ezquerra wrote:
>> > On Fri, Feb 03, 2012 at 12:16:07PM +0100, Angel Ezquerra wrote:
>> What I meant is that if you make a commit on the parent repo that
>> selects a different subrepo revision, the corresponding _subrepo_
>> revision should be made public. The parent repo revision created by
>> the commit should of course be draft.
>
> And I still do not agree this the right thing to do.
>
>> >> 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.
>>
>> But how can it do so? Let's say that I have a repo P and a subrepo S.
>> I commit revision A on P, which refers to revision B in the subrepo.
>> Both are in draft state.
>>
>> Now I go into S and use mq modify S's subrepo revision B, getting B',
>> which I can do because it is in draft state. I just broke P's revision
>> A!
>
> Obsolete concept could gracefully detect and "handle" such situation. The A
> revision will be tagged as "out of sync" and obsolete marker even allow
> automatic resolution to an A' pointing to B'.
>
> We just need the obsolete concept to land soon :)
>
>> How can mq protect me from that? How can it abort? It does not know
>> nor care that S is a subrepo! Maybe it should, but to do so it would
>> need to break a pretty basic principle of how subrepos work, which is
>> that a subrepo is just a repo.
>>
>> Personally I would not mind if the parent repo to subrepo relationship
>> was a bit more bidirectional. It could make fixing these sort of
>> issues way easier, but I think that opens a whole different
>> discussion...
>
> I think that having a way to know that a repo is currently used as a subrepo
> won't hurt for some rare situation as this one.
>
> --
> Pierre-Yves David

If the obsolete concept could handle this, and if a repo had a way to
tell that is being used as a subrepo, then I agree with you that it
would not make sense for changing the subrepo revisions from draft to
public.

Hopefully this will land soon as you say. It is all too often that I
have to deal with people rewriting history in a subrepo, only to
discover that they have broken their parent repo!

Angel