[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: removing directories
RE: removing directories
Wed, 5 Sep 2001 12:33:35 -0700
Works like a charm and it's even in the doc under C.1.4 Excluding
directories. Now that I know what terminology (removing verses excluDing) I
should be searching for, it was easy to find in the doc.
From: John Minnihan [mailto:address@hidden
Sent: Wednesday, September 05, 2001 10:33 AM
To: Schwenk, Jeanie; address@hidden
Subject: Re: removing directories
> I need to be able to customize what gets checked out and how it's
> for differing environments. This seems pretty basic.
> What started this is the contractors we have placed the SAME files in
> places originally and kept only one environment updated completely. We
> ended up with inconsistent behavior across all environments. To correct
> that, I have removed redundant copies and kept the correct up-to-date
> from the repository. This however brings up a different problem. We
> to be able to use TEST and DEV with some of the files from PROD. The top
> the repository looks like this because we have three environments:
> These three now contain distinct files but ALL environments need the files
> from systema/environments/prod/lib_ext.
> Each env has a lib_ext directory (also contains directories) in the repos
> because I can't remove them (see 7.3 in the manual). Isn't there a way
> around this? I need to grab the lib_ext dir from prod and plop it into
> checked out version of the other two environments. CVS will not let me
> Is it best to just check both sections out independently and then have a
> script mv the lib_ext to where it needs to be? I haven't been able to
> up with any way to change the repository structure to allow what is
> Should I try renaming directories? All the ideas I've come up with seem
> brute force ... there must be a better way. If I could just rid of the
> pesky directories in the repository, this problem would go away. Perhaps
> am looking at this the wrong way.
> Here's the two important lines from the modules file:
> PRODLIB -d lib_ext systema/environments/prod/lib_ext
> TEST -d test systema/environments/test &PRODLIB
> Here's what happens when I try to checkout TEST (which makes sense):
> cvs checkout: Updating test/lib_ext
> cvs checkout: Updating test/lib_ext/ifx_java
> cvs checkout: Updating test/lib_ext/ifx_java/lib
> cvs checkout: Updating test/lib_ext/ifx_java/proxy
> cvs checkout: Updating test/lib_ext/systema
> cvs checkout: existing repository
> /export/cvsroot/systema/environments/test/lib_ext does not match
> cvs checkout: ignoring module PRODLIB
Try excluding stuff in your modules def's using the shebang notation
(that is "!"). I do stuff like this on very large modules, excluding
things nested in the tree that I don't want in various checkouts.
Define one module to be the 'universe'. I have developed the habit of
explicitly naming this module 'xxxxuniverse', where xxxx is the overall
product or project name. Then, selectively define what you want in each
of the environments. Ignore the physical structure of the repository
for this exercise. Just scratch together a quick Wish List. i.e.
"Module Foo should be dirA, dirB, dirF and dirG but nothing else.
Repeat this exercise for each environment you need to create.
Then methodically add corresponding def's to the modules file for each
of the above. You may have to tweak the def's a few times before you
grok this technique (I certainly did). Here's an example:
# in the defs below, the shebang is used as an exclude modifier. jbminn
-a !engineering/autobuild !engineering/products !engineering/tools
-a !engineering/autobuild !engineering/buildsystem
!engineering/products !engineering/quality engineering
autobuild -a !engineering/products !engineering/quality