|
From: | Frederic Brehm |
Subject: | Re: how to check out a project which contains modules from different branches |
Date: | Thu, 11 Nov 2004 08:29:57 -0500 |
Also, useful to our environment, each of those cvs checkout commands can have different CVSROOT values. Once the checkout is done, CVS keeps track of the repository for each directory and there is no problem with update or commit.
BTW, since the checkout.{sh,cmd} file is version controlled, this is one way to get around the static module definitions in CVSROOT/modules.
Another beneficial side effect is that your build script (put it in the X-wrapper module) can assume the directory structure created by the checkout script, and it is version controlled along with that structure.
I also added a script to check for the presence of third party modules required by the build script. If it didn't find something, it pointed to a file with instructions on how to order/download/create the required software.
What's my measure of success? Well, I'm no longer working on the project (I just did the SCM), but the project has grown and I see that the developers keep files in the wrapper module up to date, AND nobody asks me to fix anything.
Fred At 08:30 PM 11/10/2004, Pierre Asselin wrote:
Would a two-step process work for you ? Recently I've been thinking about a "wrapper" project. Something that would work thus: $ cvs checkout X-wrapper U X-wrapper/README U X-wrapper/checkout.sh and the README file would say: Run "sh checkout.sh" to get the rest of the tree. Bye. The checkout.sh script would contain these commands, cvs checkout C cvs checkout -r branch_2-5 A cvs checkout B and by running it you would get the correct revision of each subtree. The script is rev-controlled, so it can track changes in branch tags when subprojects get merged to their trunks. I guess this sort of thing (programmability) comes more naturally in *nix. Bah, even Windows lets you write a checkout.bat, so it will work there too.
_______________________________________________________________ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/
[Prev in Thread] | Current Thread | [Next in Thread] |