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
