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

Simon Kirk Simon.Kirk at pinesoft.co.uk
Mon Jan 30 13:36:03 UTC 2006


Avi Bryant wrote:

>
> On Jan 27, 2006, at 8: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?
>
>
> No, I don't think I would have said that - I certainly don't agree  
> with it :)  What do you find weak about the merge and diff tools in  
> Monticello?  I suspect it may be a matter of being poorly documented  
> (which they are) rather than technically inferior (I would, in fact,  
> claim the opposite).  

*blush*, I think I may have done a bit of a switcheroo there. Reading 
this, you actually said pretty much the exact opposite of what I 
mentioned before wrt version delivery vs source control. My apologies.

I'm starting to be a bit redundant in my replies, sadly, but you appear 
to have hit the nail on the head without my having to spell it out: the 
documentation of the MC interface and capabilities is pretty unhelpful. 
I've already said to Cees (and referenced it to Colin - I won't repeat 
it again) about how important I think an SCM is the transition to 
Squeak. I think you've done the most important part well: Making 
something that *works properly*. But almost as important is making it 
easy to understand. Again, I've learnt a lot more about MC via this 
thread than I have by the MC documentation, or old posts to the mailing 
lists.

Sure, I could learn a lot more if I actually used it properly, I fully 
admit that. But my time is probably like anybody elses: Very limited, 
and given that I'm the only person really using Squeak at the moment in 
my team, trying to understand MC's performance and process in a 
multi-developer environment is difficult without documentation and 
illustrated examples as there simply isn't anybody else working on my 
source tree :)

Another point other than documentation is the "friendliness" of the GUI. 
Yes, it's very clean and simple, but it's not very inviting, or 
intuitive for the uninitiated. There were also some comments from 
Andreas and Stef mentioning their perceived weaknesses of the GUI. Is 
this something that's being adressed in MC2?

> The one thing that's awkward to do in  Monticello is to cherry pick a 
> small number of changes from one  branch and apply them to a different 
> branch, rather than merging  entire branches - in fact, Monticello 
> goes smoothest if you have the  (sometimes unrealistic) discipline and 
> foresight to implement any  change as an independent branch from the 
> earliest point in the  ancestry at which it could have been made, to 
> maximize the potential  places where you could merge it in.  MC2 will 
> do this better, but  even in MC1, the worst case is that you cherry 
> pick "manually"  without the ancestry getting correctly recorded and 
> risk some  spurious conflicts later on in face of a repeated merge.

An interesting point here, as the process you're suggesting is pretty 
much the process that we had implemented at my previous job: That any 
change is made in an independant branch. Given that this is something 
that you have clearly thought about before; it would appear that Colin 
was right when he suggested that MC was in fact dead-right for my 
requirements.

FWIW I think you're right that such a discipline is sometimes 
unrealistic: But that's ok, software development is always a tangential 
approach to an unattainable ideal reality.

Ooh, that sounds pretentiously good. I think I should patent it for 
management training ;)

>>
>> Similarly, there was a system that Avi wrote a while back (I think  
>> this was pre-MC) called DVS. However the archive on squeak dev  isn't 
>> clear on exactly what it was. From what I read it seemed much  more a 
>> "snapshot all of the image and shove it straight into  whatever scm 
>> we're pointing at" system, rather than dealing with  individual 
>> files. I may however be doing it an enormous injustice  here.
>
> Replace "all of the image" with "all of a package" and you've about  
> got it.  I really wouldn't recommend going back to DVS.

Don't worry I wasn't advocating that :)

>> So having gone through all that preamble (and that hopefully  
>> whatever poor souls have made it this far now have a handle on the  
>> way I used to work) I can ask the simpler question: Using Squeak  how 
>> would one go about developing a system in a safe, recordable  and 
>> easy manner in a multi-developer environment, while maintaining  
>> linkage with a bug-tracking system such as bugzilla, in a way that  
>> is non-obtrusive* to the developer?
>
> Here's a possible set of practices:
> - Start out by having a mainline/HEAD branch in Monticello, named  
> after the product.  If your package is "Foo", version names might  
> look like Foo.2.0-avi.1, Foo.2.0-cwp.2, etc.
> - When addressing an issue recorded in bugzilla, start by loading the  
> earliest mainline release in which the bug is evident or in which the  
> feature could be implemented.  Make the fixes/changes, and then  
> commit and name the version after the issue, eg, Foo.bug45-avi.1.   
> This may be a single version, or it may turn into a branch (Foo.bug45- 
> avi.2, Foo.bug45-avi.3, etc).  Automatically add the note to bugzilla  
> when you see the version name of that form.
> - Periodically integrate these bug branches into the appropriate  
> product branches (load the latest version from the product branch,  
> select the latest version on the bug branch, press Merge, deal with  
> any conflicts, and then commit back the merged version as the next  
> version on the product branch with an appropriate note).
>
> Does that make sense?
>
> Avi

Brilliant - that's exactly the kind of breakdown that I wanted. It seems 
embaressingly simple when laid out like that, but perhaps this is 
exactly the kind of thing that ought to also be in the MC domentation?

I'll repeat the question I asked to Colin: Does MC have any kind of 
pre/post "commit" hooks that would facilitate the ability to 
automatically add bugzilla notes?

Cheers,
S



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




More information about the Squeak-dev mailing list