Managing only a few files in a directory tree?

[pmts]

Hi, folks --

Ok, I'm old: I used RCS in the *80s*. :-)

I manage a suite of commercial, compiled apps in a handful of directories
in a directory tree, and each directory has one or two config files that
drive the behavior of the binaries therein. Doing a "cvs import" seems to
import *all* files in a directory, including the binaries that really don't
benefit from being managed in CVS. Throwing in a ton of -I's to ignore
certain files is a possibility, if somewhat ungraceful.

What's the best way to set up a CVS module or project which holds only the
couple of config files in each directory in the tree? What I've used works,
but is, shall we say, unpleasant. :-)

Thanks!

Don

[Todd Denniston]

Post by pmts
Hi, folks --
Ok, I'm old: I used RCS in the *80s*. :-)
I manage a suite of commercial, compiled apps in a handful of directories
in a directory tree, and each directory has one or two config files that
drive the behavior of the binaries therein. Doing a "cvs import" seems to
import *all* files in a directory, including the binaries that really don't
benefit from being managed in CVS. Throwing in a ton of -I's to ignore
certain files is a possibility, if somewhat ungraceful.
What's the best way to set up a CVS module or project which holds only the
couple of config files in each directory in the tree? What I've used works,
but is, shall we say, unpleasant. :-)
Thanks!
Don

1) understand, that unlike RCS, when you put files from a directory under VC
that directory is not now under control, i.e, importing your current structure
will not make the directory imported into a CVS 'sandbox'.

2) considering 1, the easiest thing to do would be:
copy the directory structure with config files and import it, then do a
checkout and populate the checkout with the appropriate binary files.

3) alternative to 2 is to create a repository directory,
check it out to a sandbox,
move the operational directory(ies) into the sandbox,
`cvs add` each directory and config file into the repository.

3 is probably what I would do, but I am strange.

[pmts]

Hi, Todd --

Thanks for your thorough & prompt reply!

I used a variant of #3, which worked very well: I stopped the services
offered by the software suite, renamed the top-level directory for the
software suite, created a new empty directory with the old name, cd'ed into
it, did a "cvs import blah blah blah" of nothing, moved the contents from
the renamed directory to this one, and then used "cvs add blah blah blah" a
bunch of times to descend to the directories containing the needed config
files, and then did "cvs add blah blah blah" to add said config files. Now
I have (only) the needed config files under version control in a CVS
repository far, far away.

Thanks again for the great advice!

Don

[pmts]

I should also have said that I did a "cvs checkout blah blah blah" right
after the "cvs import blah blah blah"...

Don

Post by pmts
Hi, Todd --
Thanks for your thorough & prompt reply!
I used a variant of #3, which worked very well: I stopped the services
offered by the software suite, renamed the top-level directory for the
software suite, created a new empty directory with the old name, cd'ed
into it, did a "cvs import blah blah blah" of nothing, moved the contents
from the renamed directory to this one, and then used "cvs add blah blah
blah" a bunch of times to descend to the directories containing the needed
config files, and then did "cvs add blah blah blah" to add said config
files. Now I have (only) the needed config files under version control in
a CVS repository far, far away.
Thanks again for the great advice!
Don