On 28/02/2007, at 1:02 AM, Bruce Stephens wrote:
Thomas Keller <[EMAIL PROTECTED]> 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 :-}
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
