src config

[Matt Lyon]

Hi,

This is more of a conceptual question than a specific "How do I...?", type of 
question, so I apologize if this is not the proper forum. I recently migrated 
our shop from VSS to CVS. We currently have two projects that exist on branches 
in our CVS repository and share a common platform code base which exists on the 
main code line. I have been tasked with investigating and implementing a 
solution for allowing developers to specify on a package-by-package (and 
perhaps an even more granular file-by-file) basis what iterations of files to 
grab for a build.

We have debated ad infinitum the notion of modularizing and productizing, but 
we would have to refactor our source layout (possibly including package 
structure and dependencies), and deployment and packaging models to support 
modularity. This does not seem feasible at this point in time, given the 
deadline pressure for deliverables on both projects. Our current model would 
allow us to maintain source commonality at the product platform level while 
placing divergent or new code on project branches that could be merged into the 
mainline at regularly scheduled intervals for releases. 

However, our developers don't feel like they have the support they need from an 
SCM or build perspective to proceed. They want to be able to configure the 
source pool in an automated fashion to support their efforts, so that with a 
single command, they can fetch (for example) V1.1 of the platform code, V1.3 of 
the UI code, V1.7 of the content code, layer on their own project branch code, 
have all of the sticky bits set correctly in their working directory, and 
create the builds they need to drive their development efforts. A reasonable 
requirement, I would concede.

One suggestion on how to overcome this challenge is the implementation of a 
ClearCase model of using configs to drive the build process at our shop. Simply 
put, an external properties file or script would be implemented that could be 
invoked to fetch, as an example, V1.1 of com/foo/*, V1.2 off of com/fubar/**, 
com/stuff/MyFile.java off of MyProjectBranch, and 
com/stuff/TheOtherGuysFile.java off the main code line for a build. The idea is 
that this separate external script or properties file could be maintained by 
developers on their project branch so that they could specify how to set the 
sticky bits for their fetch of ${src} to get the build they need. This file 
would also provide developers with an easy way to maintain visibility into the 
components that create their build.

I'm curious as to how others have faced this challenge using CVS in a 
production build environment. One idea I had was to simply create external 
.sh/.bat/.cmd scripts that could drive retrieval of source code and be invoked 
from a master build. We need a flexible and extensible approach. Any insight or 
comments would be welcome?

Matt