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