Ack, sent from a non-registered email address - apologies if a duplicate 
gets sent out.  :-)

Cheers,
Elias

-------- Original Message -------

Hi,

I'm quite curious about team software development with Smalltalk - what 
are strategies and tools that have worked for other people? I'm aware of 
Monticello, and it certainly appears sufficient for managing changes and 
configuration issues in smaller projects, but I'm interested in any 
advice that people may have for larger projects which have more rigorous 
requirements than can be addressed with Monticello alone. Any 
information regarding the areas of requirements management, change 
impact analysis, defect tracking, configuration management of other 
software engineering resources (design artifacts, documentation) would 
be most appreciated.

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.
* 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.
* 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).
* Baselines would be accomplished by merging the relevant change sets 
into a functional system image and committing that to the project-wide 
repository, along with other project resources, and then using the 
baselining functionality provided with whatever CM tool we decide to go 
with.

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?


Thanks,
Elias