On Jan 27, 2006, at 11:23 AM, Simon Kirk wrote:

> Now I find myself at the point of trying to justify Squeak for  
> development here at my current job. I've got a lot of backing from  
> "upstairs", but I want to know that if we use Squeak we can have  
> the same level of granular control over source modification and  
> control that I've had with Java in the past. To my current  
> understanding Monticello just doesn't cut it - in fact (harsh as it  
> may sound), the merging/diff tools in Squeak generally seem  
> inferior to svn or even VAJ/ENVY. I seem to recall a post to this  
> list that I read once from Avi saying that Monticello was more of a  
> version delivery system than a source version control system - in  
> other words that it was more useful as a way to deliver the upgrade  
> of a version of a complete package at once, rather than people  
> "checking code in an out" all the time as is more the case with cvs/ 
> svn. Is this right?

Hi Simon,

Perhaps a bit of history will give you the information you need to  
make a sensible choice. A few years ago I was in a similar situation  
to where you are now - moving from a file-based language managed by  
CVS, to Squeak managed by... what? Avi was consulting for some  
Seaside projects we were doing, and whipped up DVS as a way to let us  
continue using CVS with Squeak. DVS evolved to the point where we  
realized that CVS was holding us back rather than helping. So we  
added native versioning capabilities and renamed it Monticello.

It's interesting that you find the diff/merge capabilities of  
Monticello to be lacking, because really that's the one thing  
Monticello does really well. MC takes the same approach as CVS in  
that it allows concurrent development, with the ability merge  
parallel lines of development after they have diverged. In fact,  
Monticello does a better job of it than CVS, because it handles  
repeated merges without bogus conflicts. Also, it doesn't require you  
to update before committing - if someone else has committed since  
your checkout, you just end up creating a branched version that you  
can merge back into the trunk later.

If you want to have a strict branching discipline with Monticello, it  
wouldn't be hard. You could establish a convention for naming  
versions to indicate the branch it's on. You'd set that name when you  
save the first version on the new branch and Monticello would suggest  
version names that preserve that convention. On the other hand, we  
find it's pretty common to have more organic branching patterns in  
Monticello, simply because merging is so easy. With CVS you need a  
more structural discipline because it doesn't handle merges with  
complicated histories correctly. Have a look at this entry from Avi's  
blog for an example of what I mean:

http://www.cincomsmalltalk.com/userblogs/avi/blogView? 
showComments=true&entry=3291004466

All in all, I think Monticello would be a good fit to your needs. It  
was written with exactly this sort of use in mind.

> * Here I'm talking about the auditing of changes against bug fixes:  
> For instance with subversion I have a number of tools available:  
> Fisheye from cenqua allows me to track who's checking what in where  
> via RSS, and scmbug glues svn and bugzilla together such that  
> comments of the form "bug 45: Some changes for this bug" will  
> automatically put a comment into bugzilla against that bug: Getting  
> developers to responsibily and happily use bug tracking software is  
> quite a challenge!

Yeah, this kind of thing is important, but not covered my Monticello  
per-se. Have a look at SqueakSource. It provides a web front end to a  
Monticello repository, including RSS feeds with commit messages. I  
don't know of anyone that has done bugzilla integration, but I  
imagine it could be done.

Good luck with this, I hope you're able to use Squeak for your project.

Colin