On Fri, Oct 10, 2008 at 6:41 AM, Daniel Carrera <[EMAIL PROTECTED]> wrote: > Ludovic Brenta wrote: >>> >>> Of course we could teack kill_rev_locally also to accept workspace >>> changes and essentially do a workspace merge for these cases, but I'm >>> not sure if there is really a use case for this which is worth to mess >>> with that. >> >> Or teach db kill_rev_locally to only change the workspace's parent >> revision without changing anything to the workspace? > > Or make a command "mtn rollback" that is equivalent to kill_rev_locally > without changing the workspace. It should be simple enough. > > Step 1: Edit _MTN/revision to point to the previous revision. > Step 2: Run kill_rev_locally on the last revision.
One thing that I haven't seen mentioned in these conversations about "kill_rev_locally" (perhaps I glossed over it) is someone explicitly noting that if the revision in question has already been pushed to another DB, a pull from that DB will restore the revision. There is no way (for good reason) to cause a revision to be removed from remote databases. With this in mind, I think it doesn't make sense to make a "rollback" command, but arguably an option for "kill_rev_locally" to change the behavior slightly is worthwhile. -D _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
