Thoughts on Issue #962 svn undo/redo: a proposal for a soloution to the svn revert, vs. svn add/rm problems.

I was reading issue #962, and noticed the problems with svn revert and
svn add/rm were really troublesome.

I began to think about how the ideal revision control system might
handle these issues, and this e-mail is the result of those idle thoughts.
So champion, reject, or ignore the following at your leisure.....

My thoughts as user immediately switch to say, a text editor's undo/redo
paradigm.

This is really familiar to users, and would make a sensible way to
handle some of the operations propsed for svn add/remove, that get in
the way of current teatures.

On versioned stuff:
revert => revert to original checked out version.
On un-versioned, but scheduled stuff
revert => return to un-scheduled state.

undo/redo:

Reqires concepts of actions:

1. Scheduling an operation is an action (eg, svn add, svn mv, svn rm on
working copy)
2. os add/delete/modify is an action
(Note on 2. os add/delete would probably have to be coelseced into
... sum of all actions till scheduled op, or to date)

undo
    => Step back a single action.
redo
    => Step forwards a single action.

Fly in the ointment pt 1:
When undoing on a set of files/dirs what action is each file undone to?

file "a" has actions:
1,2,3
file "b" has actions:
4,5,
file "c" has actions:
4,5,6.
file "d" has actions:
4,6.

when unding the set, what do we undo to?

I'd say we undo the last action number.

What do 2 files with the same action number mean?
Means that
    a. all the files were os added/deleted/modifed, between last svn
     
        action and now.
    b. all the files had a subversion schedule action applied in the
        same command.
    c. all the files had a subversion schedule action applied in the
        same command, but a subset were os added/deleted/modifed
        before the

Fly in the ointment pt 2:

Q:Does that mean that a copy of the file or it's diffs is stored for each
svn add?
A:I don't know, it may be a nice feature, but that's not why I was
suggesting this. If this still makes sense without storing file
modifications, then that might be preferable.
This kind of feature is in danger of becoming a local branch, similar to
the "microbranch" idea mentioned on this list.

And when do I think such a proposal should be implemented?
-Definately post 1.0.

Well that's all for now
    -Rob.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 20:49:17 2003