[Cuis] Thoughts on workflow

[Juan Vuletich]

Yes. Please see my other response to this thread.

BTW, I apologize for not being clear enough on these issues...

In any case, let me repeat that this is quite young. We'll be learning 
about all this, and I hope we'll evolve the procedures and the tools. I 
mean: please tell about the flaws in the reasoning and the tools!

Cheers,
Juan Vuletich

H. Hirzel wrote:
> Is it correct to say that change sets (*.cs.st) are only for changes
> related to core classes whereas all the other development should go to
> packages (*.pck.st) files?
>
> --Hannes
>
> On 12/31/12, Casey Ransberger <casey.obrien.r at gmail.com> 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
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>     
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>