"Daniel Atallah" <[EMAIL PROTECTED]> writes: [...]
> 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. The same's true (well, sort of) for git, mercurial, darcs. The understanding is that if you mess with history in this way you'd better understand the consequences. In practice that still leaves the operations frequently useful. It's common while testing out a change (before pushing it anywhere) to want to fix it. (When using CVS I quite often used quilt for that purpose, as a short-term local VCS.) Linus didn't just want to be able to merge changes quickly, he wanted to be able to reject changes and for it to be practical for the submitters to beat the changes into an acceptable state. So git has features for doing that, allowing users to rewrite history (while keeping the old versions around for a period, to avoid losing things). monotone lacks similar features, but I'm not sure anybody would object to them being added. It just hasn't happened. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel