[Cuis] Thoughts on workflow

Casey Ransberger casey.obrien.r at gmail.com
Sun Dec 30 21:31:26 CST 2012


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



More information about the Cuis mailing list