Squeak, source control, subversion, versioning, monticello, all
that good stuff.
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
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
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?
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?
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
More information about the Squeak-dev