I think most everyone is just using Monticello (or Monticello 2).
On Thu, Nov 20, 2008 at 1:26 PM, Greg A. Woods; Planix, Inc. <[EMAIL PROTECTED]> wrote: > > On 20-Nov-2008, at 10:48 AM, Matthew Fulmer wrote: > >> On Wed, Nov 19, 2008 at 05:15:00PM -0500, Greg A. Woods; Planix, Inc. >> wrote: >>> >>> How do I get a change lost from all change sets back into a valid >>> change set? I made a change in a method in an existing system class, >>> but the change was done in a project and so showed up initially in the >>> project's change set and somehow in messing around relearning how to >>> use the change set sorter and the versions browser I managed to remove >>> the change from the project change set and now it doesn't appear in >>> any change set. The versions button when viewing the method still >>> shows the changes though. >> >> right-click on the method in the browser (or a category or a >> class). Somewhere in the menu is "add to current change set" > > Yes, it's in the cascaded "more..." context menu (middle/yellow button) from > the method name in a method pane! Thanks! I knew there had to be a proper > way to do this but I somehow missed this menu item in my frantic search for > a solution yesterday. > >>> Also how do I _really_ remove intermediate changes from the versions >>> of a method? I don't want all my intermediate changes to be kept any >>> more -- just the original and my final version. The "remove from >>> changes" menu doesn't do what I thought it would (which is probably >>> how I made the whole set of versions for the method disappear entirely >>> from the one and only change set it appeared in) >> >> Smalltalk condenseChanges > > Yeah, that's a little too much overkill as Chris else mentioned. > > I'm surprised there's still no easier way to collapse some intermediate > changes on individual methods (or even whole classes and/or projects). In > the version control / SCM world it seems to me this is a quite common > request; though it is one that's not always handled so well by more > primitive systems. > > Certainly for whole projects the file-out/file-in method Dave describes is > probably still the most complete and correct. However for trivial fixes to > one or two methods this seems overkill. > > On the other hand maybe I just need to adjust my paradigm for versioning > many things a bit more to be in line with the current state of the art in > Squeak. > > How do folks propose small changes or fixes for Smalltalk these days? I'm > still very much entrenched in the diff/patch world of CVS and similar > systems. I'm used to looking at diffs to understand changes, and I like to > read them directly in e-mail, not have to dive into the programming > environment / IDE / emacs or whatever and then perform multiple operations > just to then view the change inside the the IDE, no matter how much more > powerful the IDE presentation of the change might be. > > I am looking forward to learning to use Monticello to see if it really does > do the kinds of things I think it should do for full SCM within Squeak. > > -- > Greg A. Woods; Planix, Inc. > <[EMAIL PROTECTED]> > > > _______________________________________________ > Beginners mailing list > [email protected] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > _______________________________________________ Beginners mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/beginners
