[Sugar-devel] Keep confusion, again

[Sascha Silbe]

On Fri, Jan 15, 2010 at 02:40:50PM -0600, Daniel Drake wrote:

> I'm back in the field and I'm again seeing the same confusion about 
> Keep:
> http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016375.html
In VCS terms "Keep" is creating a new branch (***). Maybe that helps 
finding a better term?


On Fri, Jul 10, 2009 at 10:41:32 EDT, Eben Eliason wrote:
> Maybe we could always refer to "versions" as "history" in Sugar (seems 
> logical, given the Journal metaphor!). Then, we could call what the 
> new tree_id case "keep a copy" as I initially suggested, and the new 
> version_id case "keep in history", to indicate that pressing it will 
> add a new listing in the history of the current object.


Current situation:
1. Source code calls "copy()" for the "Keep" action [1] and behaves like 
that (clears object_id) [2], even in the version support branch [3].
2. In the version support branch, versioning is almost invisible to the 
user (only a date drop down box), so "Keep a version" wouldn't have any 
easily discoverable effect (especially since switching activities does 
the same).
3. In the version support branch, no clean-up is taking place yet, 
partly because we don't know which intermediate version a user might 
find useful later.


Ebens "Keep a version" could help with #3: as the user explicitly asked 
us to retain the version, we know it's important and can mark it as 
"don't delete automatically". Exact wording of the new action should be 
chosen to match this, of course.
I imagine these actions to be used as follows:
1. If the user wants to derive a new document (say a letter to her aunt) 
from an older one (e.g. letter to uncle), she could "Keep a Copy", set 
new metadata (*) and modify the document accordingly.
2. User decides the document looks fine, but wants to try a new 
approach. He uses "Keep a version" to make sure the old, good-looking 
one isn't lost when doing his weekly Journal clean-up run. (**)

So for a start, I'd suggest renaming "Keep" to "Keep a copy" (or "Keep 
duplicate") ASAP.


(*) Come to think of it, popping up a dialog to let the user enter new 
metadata isn't only improving the workflow, but might be quite a good 
way to make the user aware that it's actually a _copy_ we're taking, not 
just regular saving. It needs to be quite clear it's the metadata for 
the _new_ document, of course (which isn't exactly trivial to achieve).
(**) The garbage collection heuristic should obviously be chosen in a 
way that avoids versions that might still be useful (e.g. delete recent 
versions only as a last resort), but since it's always going to be just 
a heuristic and disk space has a tendency of being too small (requiring 
more aggressive clean-ups) giving the user the ability to mark versions 
as "don't delete" explicitly is important.
(***) In our code, it doesn't really - all history is lost. That should 
probably be fixed, even if we don't expose it in the Journal (UI).
[1] 
http://git.sugarlabs.org/projects/sugar-toolkit/repos/silbe/blobs/62cf7e21b23ecf98c3df2dd8d4c1387074c6dc86/src/sugar/activity/widgets.py#line178
[2] 
http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/blobs/master/src/sugar/activity/activity.py#line625
[3] 
http://git.sugarlabs.org/projects/sugar-toolkit/repos/silbe/blobs/62cf7e21b23ecf98c3df2dd8d4c1387074c6dc86/src/sugar/activity/activity.py#line625

CU Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100116/fda4d3fe/attachment.pgp