On Fri, Jul 10, 2009 at 10:05 AM, Martin Dengler<[email protected]> wrote: > On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote: >> On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizoso<[email protected]> wrote: >> > But are you meaning that we should name the current one "Keep a copy" >> > and when we have versions add "Keep"? >> >> No, no. I'm urging that we name it "Keep new version" now if we rename >> it, so that it's meaning doesn't change down the road when versions >> are introduced. > > "Keep new version" seems a lot closer to a description of the > implementation than of the user-desired result. Unless this "new > version" becomes the active one (i.e., the one upon which the user > continues to work, assuming they don't close the application), isn't > the result of the button press better called "Keep[ing of a] backup > version"?
I'm happy to entertain other terminology. All I'm really trying to get across is that, technically, this action is strictly not what I interpreted as "keep a copy" in the presence of versions, and I don't want to confuse the terminology later by mixing up the terms. I'd be equally satisfied, I think, by finding a better term for what I'm presently describing as "keep a copy", wherein a brand new tree_id is assigned to the copy, detaching it from the history (and collaboration scope) of the original. The fundamental issue is whether or not version/collaboration history is retained with the action, so let's ensure that we name both of these types of copy operations at the same time, even if we only have one of them for now, so that it can be extended later. Ben's suggestion of "checkpoint" could work. Perhaps "Keep checkpoint" would be better to retain the action. You're right that it's more like "keep backup version"....that is, the keep operation which retains the tree_id basically writes the current state of the activity as a version (the "just-now-previous" one), and allows you to continue working in the "most current" one. No branching, in the traditional sense, happens here. Eben >> > Regards, >> > >> > Tomeu >> >> Eben > > _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
