Squeak, source control, subversion, versioning, monticello, all that good stuff.

Simon Kirk Simon.Kirk at pinesoft.co.uk
Mon Jan 30 13:32:49 UTC 2006


Colin Putney wrote:

>
> 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.

Hi Colin. Thanks for your reply - as I've already said (but I'll repeat 
as it's well worth it), I really appreciate all the help everybody's 
been offering. A good advertisement for the community, I think.]

As I've said elsewhere, I suspect it's the impression of MC's merge 
capabilities that is the problem, rather than its actual capabilities. 
The documentation on wiresong.ca is very thin on the ground about the 
branching model, and the merging capabilities of MC. To illustrate this 
I'll point out that I've learnt way more about MC by the spawning of 
this thread and the reading of the replies than I ever did by the 
documentation available, the mailing list archives, or even (I admit 
here that my useage has been woefully inadequate - indeed it must have 
been otherwise I wouldn't have been asking the questions I did :) using 
MC. As I've already written to Cees:

"I've read through the documentation on MC are wiresong.ca, and doesn't 
help much in the description of how MC works. There are no diagrams 
describing the branching model, or dependencies. No mention of the 
'merge' button that Avi mentions in one of his replies to this thread. 
No mention of comparisons between svn/cvs/$YOURSCMHERE and MC."

There have been a lot of posts on this list over the years that I've 
seen discussing various gnarly points: documentation, acceptance of 
Squeak in the business world, etc. I think a very functional, 
well-documented and clearly illustrated SCM is key to the latter (as 
well as providing an easy way in for those of us who would like to 
contribute to the Squeak community as a whole, but aren't clear on the 
processes involved). MC is clearly already very functional, but the 
other points could do with a brush up. Of course, who's got time for 
that? ;)

>
> 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.

Having seen that, and read other comments (and gone back over MC's 
documentation), I think you're dead right. Just to clarify: I'm much 
happier with organic branch growth, and the main reason for a strict 
branching discipline was due to CVS and the need to tag branches in 
order to have sanity about merging them. However I've been using svn for 
the last year, which removes that requirement by incrementing the build 
number of the whole repository upon each commit, forming a known point 
of branching whever anybody does so. Much nicer.

The only other need for a strict branching discipline is maverick 
developers who have a habit of refactoring large swathes of shared 
library code in the main codebase that impact other people, live 
deployments, testing, etc. How would you suggest stopping people from 
being able to do this sort of thing?

>
>> * 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.

That's interesting, I shall have to take a closer look. So many things, 
so little time. Does MC have any kind of pre/post "commit" hooks that 
can be used for scripting of events into other systems? Sorry, this may 
be in the documentation here, but I'm writing about five replies on this 
thread, I'm getting lazy ;)

>
> Good luck with this, I hope you're able to use Squeak for your project.
>
> Colin
>
Thanks - I do, too, in a big way.
S



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com




More information about the Squeak-dev mailing list