[Sugar-devel] Nobody understands "Keep"

[Tomeu Vizoso]

On Fri, Jul 10, 2009 at 16:25, Eben Eliason<eben at laptop.org> wrote:
> On Fri, Jul 10, 2009 at 10:05 AM, Martin
> Dengler<martin at martindengler.com> 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<tomeu at sugarlabs.org> 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.

Should we discuss this in sugar-devel? Why not asking any of the
teachers in IAEP what is more natural for them?

Regards,

Tomeu

> Eben
>
>>> > Regards,
>>> >
>>> > Tomeu
>>>
>>> Eben
>>
>>
>