[Cuis] Thoughts on workflow

[H. Hirzel]

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


Thank you. In fact the content is well written and very
understandable. Having it in the image really means that we are
serious about following this approach :-)

--Hannes



> 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
>>
>>
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>