Hi Squeakers. Bit of an internal monologue here about something that's 
been concerning me about Squeak development for a while now: Source 
control. Please excuse the verbosity.

Specifically, over time at my last two companies I've worked with others 
on developing a development process using CVS (later Subversion) that 
allowed development to happen on a fair-sized codebase, across a team of 
up to about 30 or 40 developers. Nothing particularly special, it uses 
the idea of "branching a lot" as opposed to "branching a little", but it 
allows the tight integration of a bug tracking tool with ones source 
control, and potentially (although the reality is often less idealistic, 
obviously) keeps fixes for bugs nicely segregated from the rest of the 
code until they're merged. Note that this has always been on file-based 
languages (Java in this case). But with a major smalltalk-related 
caveat, which I'll get on to shortly.

It's how I'd like to be able to work now with Squeak, but obviously 
things are different in image-based-development-land.

Just to elaborate a little on the process: There's a "main branch" of 
development, commonly referred to (in my experience: Note that my 
terminology may differ a lot to what people are used to, so please bear 
with me :) as the HEAD with cvs/svn. The state of this branch is 
arbitrary, really - although generally for me it was always the latest 
main development/unstable/latest&greatest version of the product the 
source-controlled codebase represented.

We then also used the branch-per-product method: In an ideal world a new 
version of the product would be released to the world against a known 
cvs/svn tag. Further maintenence against that version would then be 
performed in a branch made from that tag, and would henceforth live 
seperately from the HEAD. This process could continue as futher 
maintenence releases were made from *that* branch, etc etc. One could 
end up with version numbers like, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.2.1, say. 
You get the picture I'm sure (I hope!).

We went a bit further (people may disagree here), and pushed branching 
to the extreme: We branched for each and every defect change, naming 
that branch against the bug number from our bug control software. Yes, 
it took a lot of training to get the developers used to and happy with 
this process, but once we did it became much, much easier to track 
changes related to certain bugs, merge those changes into other branches 
(ie back/forward porting bugs fixes between versions), review the 
changes for a bug atomically, etc. We were pretty happy with it.

Of course one might point out that this model pretty much negated one of 
the nicest parts of cvs/svn: that it allows developers to concurrently 
work on the same files at once, and on face value you'd be right. 
However, often we were working in a "large bug branch" that was really a 
large branch related to a large new development, with at least two 
developers (both assigned to the same bug) working on the same branch at 
once, so here the concurrent modification came into play.

Now for the caveat: The model was based upon the original development 
environment that my previous company were using before we switched to 
Eclipse, VAJ (Visual Age forJava), in other words loosely based upon 
development using ENVY - therefore loosely based on a reaonable 
Smalltalk development practice.

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?

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.

Another thing that was recently mentioned was some work around MC2, but 
I don't know if that will support the multi-developer process I 
described above either, because of the general problem I've had so far: 
Try as I might I cannot find enough information on how to manage a 
smalltalk development within a multi-developer environment. Sure, I can 
see how MC works on a high level. But for sharing code it seems like it 
just won't work in the way I envisage it.

Therefore I find myself thinking that either I don't understand 
MC/MC2/Envy and even Squeak development properly yet (highly likely as 
I've only been using Squeak since last July, and even then not 
exclusively by any means), or that the current systems out there don't 
support what I want at all, or that the development process I've 
described above is flawed.

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?

Cheers for reading, I hope it makes sense.
Simon

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


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