[Cuis] Thoughts on workflow

[Juan Vuletich]

Hi Casey,

(below)

Casey Ransberger wrote:
> Below. 
>
> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <juan at jvuletich.org> wrote:
>
>   
>> Hi Casey,
>>
>> Casey Ransberger wrote:
>>     
>>> Not saving the image totally makes sense when working on a shared artifact, but it doesn't suit my solo development style. Sometimes I work on things for a long time before sharing them, and being able to keep my work context alive is one of the reasons I love working with Smalltalk.
>>>       
>> I understand. I want to support that style too.
>>
>>     
>>> The warning every time I make a change to a method or class that's *not* a core part of Cuis seems a little bit much to me. Here's a thought: why not keep a #(registry of classes) which belong to the core, and warn about a save only in that case? I love being able to use git, but I'm not super sure I like being forced into it all the time:/
>>>
>>> -- 
>>> Casey Ransberger
>>>       
>> Ok. I guess you refer to the warnings you get when you save the image, right? I guess you're ok with the warnings when quitting without saving, as they prevent you from the need to go to the .changes log file to recover your work.
>>
>> When saving the image, you get a warning about unsaved packages and another one about unsaved changes to Cuis core (i.e. changes that don't belong in any package). Their purpose is _not_ to force you to use Git, just to remind you that saving them is good practice...
>>
>> The warning about changes that don't belong in a package is perhaps the most important. Those change sets are zapped at image save, so you might forget about them, and maybe never publish them, or save them to be loaded on another image...
>>
>> The warning about unsaved packages is less important: you can save the packages on next image start, or anytime you prefer. For this warning, a possible solution would be to ask if to suppress it in the future. Or we can even remove it, after all, it is important when you quit _without_ save.
>>
>> What do you think?
>>     
>
> Forgive me if this is a bit daft, but why do the change sets have to get zapped on save? It seems like I'd want to keep them going until I was ready to commit them. Part of the problem, I think, is that I'm not completely understanding what motivates some of the design decisions involved.
>
> Casey
>   

Well, this new way of handling code in Cuis is still young, and only 
starting to get broader feedback. Nothing of this is carved on stone! We 
need to evolve it. Besides, it seems I didn't publicize enough 
http://jvuletich.org/Cuis/CodeManagementInCuis4.html and 
http://jvuletich.org/Cuis/CuisAndGitHub.html . The first one is what I 
had in my head when I did Packages and the new behavior of ChangeSets. 
The second one are my initial thoughts on using GitHub to host packages.

Please read them, especially CodeManagementInCuis4. The main motivation 
for all this is that working with ChangeSets as they used to behave (and 
still do in Squeak and others) is a PITA. It was quite common to lose 
changes, contaminate one change set with stuff from the other, etc.

So, now, the main idea is that regular change sets are used only for 
updating the base image, and they form a sequence (the update stream). 
Stuff that doesn't belong there is better stored in some package. This 
is a key idea. If you fight it, then all the rest won't make sense. If 
you really want to keep using change sets for stuff that will never be 
part of an update stream, then we need to discuss the use case, and find 
a way to support it (or decide to abandon it!).

(There are other 'automatic' change sets for the changes you do to each 
package, and others that record what happens when you install a package. 
You can usually just ignore them.)

In particular, when you save the image, the change sets with stuff for 
the base image are removed. My thinking here is that when you are 
working on them, the result of that work is not an updated image, but a 
sequence of change sets. This works quite well, as it eases producing an 
"update stream" that can be used to update other images or for 
publication. The idea is that when you save the image, those change sets 
become part of it, you no longer need them as a separate entity. See 
that the first option of the right click menu in the Change Sorter is 
"file out and remove". It is the same thing. When you are done with some 
changes to the base image, you save the change set, and start a new 
change set for what follows. This means that there is usually one single 
change set in existence that captures changes to the base image. This 
means there's no way for change sets to get mangled! And this almost 
enforces the change sets to form a sequence (an ordered list).

To keep the discussion concrete, please give some thought to all this 
(especially CodeManagementInCuis4.html), and then describe your use case 
telling what goes into packages and what goes into change sets, at what 
times you save them, and if you save the image and when.

It will require some effort, but the result will be polishing our 
procedures and tools.

Cheers,
Juan Vuletich