[Cuis] Thoughts on workflow

[H. Hirzel]

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


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
>