[Cuis] Thoughts on workflow

Tue Jan 1 10:01:40 CST 2013

+1

2013/1/1 H. Hirzel <hannes.hirzel at gmail.com>

> 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
> >
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130101/601662c3/attachment-0002.html>