On Oct 8, 2004, at 12:32 AM, Elias Sinderson wrote:

> Currently I'm considering an approach which would utilize both 
> Monticello and another CM tool (TBD):
> * Each developer would maintain a local Monticello repository as a 
> sandboxed environment where they can make changes to their working 
> image.
> * Changes to each developers working image would be factored out as a 
> change set and comitted to a project-wide CM repository. Each 
> developer would likely work on a seperate branch within the 
> project-wide repository.

Just to clarify terminology - within a Smalltalk context, "change set" 
has a very specific meaning, of a set of code modifications captured in 
a ChangeSet object, and usually expressed in a chunk-format (.cs) file. 
Do you mean a Smalltalk change set here, or more generally "a set of 
changes", which might be expressed by a Monticello version or some 
other artifact?

> * Within the project-wide CM repository we would then be able to take 
> advantage of features such as linking change sets to requirements, 
> design artifacts, test cases, etc.

Can you explain more about your requirements here?  Is it that you want 
to associate a particular version of, say, a requirements document, 
with a particular version of the code?  Or is it that you want to be 
able to link a particular item in the requirements to the version of 
the code that implements it?  Or some combination of both?

> * Merging of change sets would probably be best left to Monticello, as 
> it is well integrated with the Smalltalk environment. An exception to 
> this would be if the CM tool we are using supports binary diffs and 
> merges (as the monticello versions are essentially zip files 
> containing package, version, and dependency information).

A binary diff/merge is hardly going to be able to reproduce the merges 
Monticello does - Monticello is aware of the structure of the data 
(where a method or class definition starts and ends, what the 
class/selector of each piece of code is, etc), and does its diffing and 
merging at that level.  No matter how good the pattern matching 
algorithm, a generic binary merge isn't going to be able to pull out 
that structure.  To put it another way, a Monticello merge always ends 
up with well-formed code, whereas there's no way a binary (or textual) 
merge can guarantee that.

> Does the above make sense? Are there other approaches or 
> considerations that I am missing? What are the hidden 'gotchas' (e.g. 
> merge issues, etc.) associated with using another CM tool as the 
> repository for a Smalltalk project?

Trying to integrate two competing SCM systems sounds like something 
that will get very hairy very quickly unless you very clearly define 
what the responsibilities of each one are (and quite possibly even 
then).  Unless there's some existing system you're trying to integrate 
with, I would personally very much incline towards building what you 
need in and around Smalltalk.  But if you really do need to use a 
flat-file CM system, you may be better off managing your Smalltalk code 
as straight text files using something like MonticelloCVS.  (Insert 
mandatory Kent Beck quote about source code in files here).

Just my $0.02,
Avi