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

> 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