sourcecode-management

Victor Rodriguez palique.st at gmail.com
Wed Aug 24 07:13:38 UTC 2005


2005/8/23, Julian Fitzell <julian at beta4.com>:
> I meant to include a link to the monticello web site which has some info
> on motivation, features, how to use it, etc.:
> 
> http://www.wiresong.ca/Monticello/

Thanks, I will certainly take a look at it.

I think something that is easy to integrate with CVS or SVN might be
worthwhile. As you mention, there might be no choice at all, but it
might also make life a little bit easier to newcomers to Smalltalk and
Squeak if we are able to use a familiar tool.. I'm finding there is a
lot to grasp, and very little documentation..

BR,

Victor Rodriguez.

> 
> Julian Fitzell wrote:
> > Victor Rodriguez wrote:
> >
> >> What about just filing out classes to individual files and checking
> >> those into SVN?
> >
> >
> > The major problem with this approach is that you need to add and remove
> > files from CVS or SVN when you add or remove classes.  It also doesn't
> > handle the case of method overrides on other classes, which Monticello
> > handles seamlessly for you (as long as you put the methods in a properly
> > named category).  Also, as you point out, filing in all the classes over
> > and over even though they haven't changed can be slow in a large project.
> >
> >> A disclaimer: I just started playing with Smalltalk and Squeak and
> >> know very little of change sets, and nothing about Monticello.
> >>
> >> To keep my own code in CVS I have been thinking about writing a little
> >> tool to file out all the classes in the category I'm using for them
> >> (I'm assuming this is possible). Then I would use my CVS client
> >> (XEmacs) to check-in the modified files.
> >
> >
> > The tool you are describing sounds basically like the original
> > Monticello, now called MonticelloCVS.  The only real difference being
> > that we decided, for various reasons after months of trying different
> > approaches, to use one file per package instead of one per class.  We
> > also determined an best-possible ordering of code to minimize cvs
> > "conflicts" by reducing the amount of code reordering going on when you
> > add methods, etc.
> >
> > The original monticello worked great except that it suffered from the
> > same problems that CVS always does: it doesn't have any syntactic
> > understanding of the code or the changes, so "conflicts" can begin to
> > run rampant because of your merging patterns or because people are
> > working in physically-proximate but unrelated locations in the source code.
> >
> > The new Monticello (and the newer one in development) addresses these
> > issues by storing version history and adding an understanding of what a
> > method is, what a comment is, what a timestamp is, etc.  It provides
> > branching, merging, conflict resolution, multiple repositories, etc. all
> > quite simply from within the image.
> >
> > If you can just use Monticello, I would highly recommend it.  If for
> > some reason, you need to use CVS (hey, we've all worked in places like
> > this :) ) then I would definitely suggest seeing if you can use or tweak
> > MonticelloCVS to your needs rather than reinventing that wheel.
> >
> > Julian
> >
> 
> --
>    Julian Fitzell  --  Beta4 Productions
> julian at beta4.com  --  http://www.beta4.com
> Seaside: http://seaside.st/
> 
>



More information about the Squeak-dev mailing list