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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs