[Monotone-devel] Re: revert

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> I think there are still some problems lurking in revert as well, for one it
> leaves renamed things laying around after reverting the renames. I've tried
> a few times to make revert work based on the editable_tree interface rather
> than just looking for missing files and recreating them but this turns out
> to be quite tricky and I've never actually managed to make it work quite
> right. The last attempt I made did at least get revert upgraded to use
> roster style checks rather than csets but it still doesn't actually replay
> the pending changes in reverse.

I had an idea; what we really want here is a command line editor for
change lists.

'revert' in general is undoing the current changelist; either the
explicit one in _MTN/revision, or the implicit one of changed file
contents.

Perhaps a set of commands similar to 'mtn conflict' would be useful:

'mtn changelist show [--last n] [--from n] [--no-content]'

    Output _MTN/revision, and list of changed files; similar to 'mtn
    inventory' output. Number each item for later reference.

    --last, --from are similar to log. --no-content doesn't show content
      changes, but the numbering is still the same.

'mtn changelist undo n'

    Undo the nth change. For files, do 'revert' unless there are local
    changes; get confirmation in that case, or move to _MTN/resolutions.
    For _MTN/revision, just delete it from the changelist. If that's not
    possible (because of later dependencies), warn the user, and add a
    reversing change. Or maybe just error, and describe the problem.

    Alternately, edit later changes to take account of the deleted
    change. That seems possible in principle, but hard in practice. Just
    detecting the dependency might be hard in general, now that I think
    about it.


'changelist undo' needs to be available as an automate command, so
GUItone and Emacs DVC can provide a more visual interface to this.

There have been times when I've edited _MTN/revision; it seemed the
easiest way to undo something I had done by mistake. Although sometimes
it was because of a mtn bug. This would provide a more structured way to
do that (at the risk of introducing yet more bugs :).


The current mtn code does not support editing changelists in this way.
We can operate directly on a cset, but it doesn't provide any
consistency/dependency checks.
 
Example of a change that can't be simply deleted:

1) rename directory foo to bar

2) rename file bar/file1 to bar/file2

Can't undo 1), because 2) depends on it

Perhaps a cset should maintain some dependency information; "this file
rename depends on that directory rename", "this attr change depends on
that file rename". A tree could maintain similar info; "this node was
renamed by that cset entry".

Sounds like a lot of work.

-- 
-- Stephe