[bespin] Undo/Redo + Collab + time machine
Julian Viereck
Joe and I dicussed for quite a long time during the status meeting how
we could get undo/redo working together with collaboration as well how
we could get things working for time machine.
Let me explain the current plan at first.
When collaboration is turned on you can't just undo/redo the way we do
it now. The reasons is that you have to take care of the changes
someone else did. Person A could typed "Hello World" and Person B adds
"Blame". If person A undoes, the text of person B should still be
there. Sounds simple but that's a little bit more complicated to get
it going.
The solution to solve this problem is to create a content based diff
of person's a change (that shows in basic +Hello World). This patch is
reversed applyed to the current state of the file. If things work
fine, the model has now undone the changes of person A (typing Hello
World) but the changes of person B should still be there (adding
Blame) as this was not affected by the patch, right?
If you can't apply the patch this indicats someone else did some work
on the same line in the meantime and you can't undo your work anymore
=> the model keeps untouched.
To don't "waste" to much memory these patches should just be created
as they be needed. The changes done by any person are saved by model
based deltas as we do it for now in the undo/redo mechanism. To create
a patch the model would be put back in the state where you want to
take the diff from. That can be done by the same we we perfom undo/
redo now in the model. The patch would then be the difference between
the point in time before myself did a change to after the change has
happened. How ever, as it turnes out we could end up with a lot of
things we need to undo to get back to just create the patch.
Let's say the undo stack looks like this:
0 1 2 3 4 5 6
A1, B1, A2, B2, -A2, B3, -A1
That means person A did a first change, then person B did another
change, then person A did a change again, then person B did a change,
then person A undoes his secound change etc. The numbers above are
just index numbers for this changes. You see, we don't haven't deleted
anything from the undo stack! We would do that in a normal editor, but
in this case when collaboration is turned on we can't do that. We have
to add a new action/change that undoes the former change but this
change is still added to the undo stack.
But let's get back to the basic issue: after person B did his secound
change person A undoes. This means the model has to put in the state
before A2 and then later in the state after A2. This patch is then
applyed and results in -A2. If we do this for -A1 this means we have
to undo B3, undo -A2, undo B2 undo A2 undo B1 save that state undo A1
and create the patch. You see how the numbers of undos growed? That
could led to big performace problems! To avoid this we could hold up a
copy of the model at the state we are "undoing" at the moment. So in
the case of creating -A2 we put the editor int the state before A2 to
create the diff. This model is saved completly. If we want to undo
another step, we just have to undo B1 save that state, undo A1,
compute the diff and apply it to the current state of the model. The
numbers of undo is much smaller now. The saved model version for
"undoing" would now be the state before A1. If you want to redo
things, that would help as well.
Sound that all right?
Two other things to meantion:
1) when a mobwrite change arrived, the whole document is replaced at
the moment. That's bad as it eats up memory if you want to undo over
every change. So changes of mobwrite should really just change the
code they does and not replace the whole document.
2) mobwrite doesn't save at the moment what was deleted. It just says
from that point 5 chars were delted etc. One plan for time machine was
to save mobwrite deletas of every change we do to the model on the
server. If you want to get to any point in time with the model the
backend just had to add the deltas all up again and the model should
be in the state you want it to be. But as you said you just deleted 5
characters you lost information and you can't undo that delta again.
To make a mobwrite delta based time machine work these delte has to
hold up the information of what exactly was delted.
---
This where just my thoughs as well as a conclusion of what Joe and I
have discussed over the last weeks. I will send a mail on how we could
get this implemented to the model and how we have to change things in
the action's undo-manager but not this evening ;)
Cheers
Julian
@JOE: I hope you could follow a few of my thoughs now better.
Otherwise just scream up!
Alex Iskander
To avoid this we could hold up a
copy of the model at the state we are "undoing" at the moment. So in
the case of creating -A2 we put the editor int the state before A2 to
create the diff. This model is saved completly. If we want to undo
another step, we just have to undo B1 save that state, undo A1,
compute the diff and apply it to the current state of the model. The
numbers of undo is much smaller now. The saved model version for
"undoing" would now be the state before A1. If you want to redo
things, that would help as well.
Sound that all right?
Julian Viereck
My thoughts now go to the "time machine.” I think, given that we cannot guarantee that undo/redo will always just work (with collaboration), the performance of the “time machine” is very important. I think it would be really nice if it was possible to scrub through the file like you would a movie in a media player. This would allow it to compensate for any shortcomings in the undo/redo system. If the performance is adequate, it may be a better solution than undo/redo ever was; I think most likely, if you are undoing hundreds of times, you really mean to go back in time, not undo.
Unfortunately, I have been a bit out of the loop due to the fact that I have to attend college, so I’m not really sure what is planned at the moment.
Alex Iskander
there are two things. Time machine is based on the server. If you want to undo, that should work as quick as possible. Asking the server for the state of a file at a certain point in time and use this information for undo/redo would slow things down. That's why I think we should keep time machine out from beeing direclty needed for undo/redo.
If we could get Cover Flow working with files as you do this in iTunes... that could be great (although I don't know what use that should be :D).
The secound thins is, you can't use time machine to undo changes as you have to take care not to undo the other people's changes. That's exactly why we have to invent the undo/redo mechanism and not base everything with undo/redo on time machine.
Ohh, it feels good to have someone up there that questions everything I/we planed. So don't worry about that ;)
CheersJulianAm Sep 2, 2009 um 4:03 PM schrieb Alex Iskander:Hi Julian et. al.,To avoid this we could hold up a
copy of the model at the state we are "undoing" at the moment. So in
the case of creating -A2 we put the editor int the state before A2 to
create the diff. This model is saved completly. If we want to undo
another step, we just have to undo B1 save that state, undo A1,
compute the diff and apply it to the current state of the model. The
numbers of undo is much smaller now. The saved model version for
"undoing" would now be the state before A1. If you want to redo
things, that would help as well.
Sound that all right?I think that this idea of caching the state is very good. It pretty much solves the biggest parts of the performance issue for undo/redo.My thoughts now go to the "time machine.” I think, given that we cannot guarantee that undo/redo will always just work (with collaboration), the performance of the “time machine” is very important. I think it would be really nice if it was possible to scrub through the file like you would a movie in a media player. This would allow it to compensate for any shortcomings in the undo/redo system. If the performance is adequate, it may be a better solution than undo/redo ever was; I think most likely, if you are undoing hundreds of times, you really mean to go back in time, not undo.Based on some of what I’ve seen/read/heard, this may be in the plan. Unfortunately, I have been a bit out of the loop due to the fact that I have to attend college, so I’m not really sure what is planned at the moment.Any thoughts?Cheers,Alex
Joe Walker
2009/9/1 Julian Viereck <julian....@gmail.com>
Let's say the undo stack looks like this:
0 1 2 3 4 5 6
A1, B1, A2, B2, -A2, B3, -A1
That means person A did a first change, then person B did another
change, then person A did a change again, then person B did a change,
then person A undoes his secound change etc. The numbers above are
just index numbers for this changes. You see, we don't haven't deleted
anything from the undo stack! We would do that in a normal editor, but
in this case when collaboration is turned on we can't do that. We have
to add a new action/change that undoes the former change but this
change is still added to the undo stack.
'hg rollback' works in the same way - it's ok so long as you have not pushed between the commit and the rollback.
I think we can use this to maintain a linear undo history, and therefore save memory.
I'm trying to get my head around tracking history from out of mobwrite. If only I had a "mobwrite log" command!
Joe.
Joe Walker
Julian Viereck
I'm trying to get my head around tracking history from out of mobwrite. If only I had a "mobwrite log" command!
Joe Walker
does mobwrite has history management integrated? I'm not sure what you want to tell me with that sentence...I'm trying to get my head around tracking history from out of mobwrite. If only I had a "mobwrite log" command!
No - it doesn't I was wanting to be able to type 'mobwrite log' the way I could type 'hg log'. It's a little harder than that though ...
Joe.