[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to check out a project which contains modules from different bra

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

I have done this for a project. It was very successful. It was in MS Windows, too.

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.


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/

and the README file would say:
    Run "sh" to get the rest of the tree.  Bye.

The 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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]