Re: [Monotone-devel] Re: Release

[William Uther]

On 28/02/2007, at 1:02 AM, Bruce Stephens wrote:

> Thomas Keller <address@hidden> writes:
>
> > Richard Levitte - VMS Whacker schrieb:
>
> [...]
>
> > > Hmm, you're right, and still, one of its children,
> > > d9df3690ffc222d7f6b1a65c34bfdfdcd6ad6735, is in nvm...
> >
> > And its entirely my fault! Now how can we back this out?
>
> We can't, I think.
>
> A more interesting question is how it might be made possible to back
> out such a change.  In particular, suppose there's just one revision,
> or one fork: how could we indicate that that fork is a dead end (and
> so it shouldn't interfere with propagate, participate in merge, etc.)?

Can there be an "ignore this revision" cert?  It would be like a  
testresult cert only it would cause monotone to ignore that revision.

> In this case the revision's now an ancestor of all the heads, so we're
> stuck with it.

This is monotone!  mtn up -r the revision you want to make a new head  
from, and then commit from there.

In particular, you could mark a revision and all its children with  
'revoked' certs.  Then you would pluck its child changes onto its  
parent and commit that.  If there were changes propagated from  
somewhere else then you'd just propagate them into the new head.

e.g.

 y  a
  \ |
   \|
    b
    |
    |
    c  x
    | /
    |/
    d
    |
    e

now we decide we don't want y merged into this branch.  You can't use  
a normal revoke on that rev because by die-die-die you'd have  
issues.  So you add a new cert to b, c, d and e saying "ignore this  
revision" - a testresult of 0 might work.  This has to be a 'flag  
day' kind of thing because you don't want anyone committing any  
children of any of them either.  I'll mark these cert-revoked  
revisions with ().  Then you make a new child of a that has the b-c  
changes plucked.  Then you merge x into this new head, then you pluck  
d-e changes.  The result looks like this:

 y  a
  \ |\
   \| \
   (b) f     <-- f has the b->c changes plucked
    |   \
    |    \   x
 x (c)    \ /
  \ |      g
   \|      |
   (d)     |
    |      h     <-- h has the d->e changes plucked
   (e)

Now development continues from h.  That has all the stuff that was in  
e, except for the changes in y.  You just need to make sure noone  
commits anything else to (e).

When it comes time to merge in the y branch, you just merge it into  
the new head, and everything works.

Unless I misunderstand what you're saying.

Cheers,

Will       :-}