monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Release


From: Bruce Stephens
Subject: [Monotone-devel] Re: Release
Date: Tue, 27 Feb 2007 14:02:38 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.94 (gnu/linux)

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

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

I guess once branch-renaming becomes possible, one could contemplate
putting all the acceptable revisions into a new branch, then renaming
so that the change of branch would be less annoying?

> If we disapprove this revision, can the branch be merged into nvm
> later on?

I think the files that were added in that revision (some test files?)
would then be permanently dead, so no.

[...]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]