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