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? _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
