Selon Thomas Keller <[EMAIL PROTECTED]>: > I'd do it "safely" without messing around with _MTN/revision and move > the current changes aside to re-apply them later on: > > $ mtn diff > current_changes.txt > $ mtn revert . > $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597 > $ patch -p0 < current_changes.txt
The problem with this "safe" approach is that it is unsafe in the presence of new, moved or deleted files. A new but uncommitted file will appear as a hunk in the diff, it will survive the "mtn revert .", and applying the diff will double its length. A moved file will actually not appear in the diff at all, except as a comment; reapplying the diff will lose that change. A deleted file may appear as a hunk in the diff (I'm not sure anymore; it may also appear only as a comment) in which case reapplying the diff will not delete the file, only make it empty. > 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? -- Ludovic Brenta. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
