[Cuis] Thoughts on workflow

[Juan Vuletich]

H. Hirzel wrote:
> Juan,
>
> I think once one has found your web page where you explain how *.cs.st
> files are for the core only and the rest should be handled by *.pck.st
> files it is very clear. And it is a solution to a long standing
> problem which created a lot of discussions in the past years on the
> Squeak list.
>
> However at the moment I do not find the access to that page any more.  :-(
> I do not see a link to it from http://www.jvuletich.org/Cuis/Index.html
>
> And I think as this is a major new conceptual step in terms of source
> code and update management (at least from the point of view of a
> Squeak or Pharo Smalltalk user) this deserves to have a workspace in
> the 'help' menu. Or at least a link in the 'Welcome' window.
>
>
> --Hannes
>
>   

Added them to the help menu.

Cheers,
Juan Vuletich

> On 12/31/12, Juan Vuletich <juan at jvuletich.org> wrote:
>   
>> 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
>>>
>>>
>>>
>>>       
>> _______________________________________________
>> 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
>
>
>