[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: revert
From: |
Stephen Leake |
Subject: |
[Monotone-devel] Re: revert |
Date: |
Tue, 11 May 2010 04:56:47 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt) |
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
- [Monotone-devel] bugfest analysis, Thomas Keller, 2010/05/09
- Re: [Monotone-devel] bugfest analysis, Derek Scherger, 2010/05/09
- Re: [Monotone-devel] bugfest analysis, Thomas Keller, 2010/05/10
- Re: [Monotone-devel] bugfest analysis, Stephen Leake, 2010/05/10
- Re: [Monotone-devel] bugfest analysis, Derek Scherger, 2010/05/10
- Re: [Monotone-devel] bugfest analysis, Thomas Keller, 2010/05/10
- Re: [Monotone-devel] bugfest analysis, Stephen Leake, 2010/05/10
- Re: [Monotone-devel] bugfest analysis, Derek Scherger, 2010/05/10
- Re: [Monotone-devel] bugfest analysis, Stephen Leake, 2010/05/11
- Re: [Monotone-devel] bugfest analysis, Stephen Leake, 2010/05/11
- [Monotone-devel] Re: revert,
Stephen Leake <=
Re: [Monotone-devel] bugfest analysis, Timothy Brownawell, 2010/05/09
Re: [Monotone-devel] bugfest analysis, Stephen Leake, 2010/05/10
Re: [Monotone-devel] bugfest analysis - final points, Thomas Keller, 2010/05/10