phases and subrepos
pierre-yves.david at ens-lyon.org
Fri Feb 3 20:09:46 CST 2012
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
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
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.
More information about the Mercurial-devel