Re: Automated source config model?

[Laurie Harper <zo...@holoweb.net>]

Why not use CVS tags to do this? Just apply a cvs tag to the branches and
revisions that are part of the particular configuration a developer needs.
Something like:

Cvs tag -r V1.1 my_tag platform
Cvs tag -r V1.3 my_tag ui
Cvs tag -r V1.7 my_tag content
...

Then all the developer has to do is 'cvs update -r my_tag'. If they need to
pick up a file from a different branch, all they have to do is move the tag
onto the appropriate revision of that file.

If you use cvs modules to partition your source base into modules, it gets
even easier. And no scripts or config files to maintain.

L.

On 8/30/02 10:45 AM, "Matt Lyon" <ma...@stargus.com> wrote:

> Hi,
> 
> 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
> branch to grab files off of to 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 by Ant 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 Ant and CVS in a
> production build environment. One thought I had was to investigate using the
> Ant-Contrib <foreach> task to iterate over a 'src.properties' file that would
> contain the ingredients, so to speak, that are passed to a fetch target (e.g a
> <cvs> task that would read in the 'src.properties' file and grab the correct
> revisions of every file needed to build the product for a specific developers'
> build case). Another idea I had was to simply create external .sh/.bat/.cmd
> scripts that could drive retrieval of source code and be invoked from Ant via
> an <exec> task. It's not really going to be scalable to put hacked build.xml's
> on every branch that have 1.000 line-long fetch targets that set all the
> sticky bits correctly; we need a more flexible and extensible approach.
> 
> Thoughts?
> 
> Matt
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>