Re: Suggestions for using CVS with a system/software project

[Dustin Puryear]

Thanks for the suggestions Mark.

We actually began importing the distribution version of externally developed
software that we modify (we import as SOFTWARE_VER_DIST), and then we check
in our changes on top of that. I made the decision to not note the version
of the distributed software in the directory, but just in the CVS log. So if
we import, say, Apache-1.3.25 I just import into:

projectname/components/apache/apache

Instead of:

projectname/components/apache/apache-1.3.25

I don't see a real need to note the original version in the directory name
itself. One reason to do this is that we may later on move to a newer
version and bring out changes over. That would require that we either delete
from CVS apache-1.3.25 and create the new directory, or leave the old
directory and create a new one. By using a directory without a version name
we can keep a consistent area for that code.

As far as software that we need but do not edit, I like the golden release
tarballs idea the best. Why check in code to CVS when you aren't going to
actually use the benefits of CVS? I suppose we can maintain a distribution
directory that runs parallel to CVS for the golden release tarballs:

/home/cvsroot
/home/goldenrelease

When I do a 'make install' under projectname my Makefile will know to grab
files from /home/goldenrelease as well as compile code from CVS.

So instead of having thirty to forty software packages from ports under CVS,
we will have only what we customize, and everything else goes into
/home/goldenrelease (or wherever).

Thoughts on this?