[ On Friday, April 7, 2000 at 09:19:12 (-0400), Laird Nelson wrote: ]
> Subject: Importing of CVS sources question
>
> I started by importing cvs v1.10 lo these many months ago into our own
> CVS repository. Now I pulled down CVS v1.10.8 and imported that onto
> the vendor branch following the recommended steps. Everything worked
> fine. Then I went to make it.
>
> On making lib/getdate.c, it looks like that's made from lib/getdate.y.
> During make, therefore, it tried to overwrite the existing checked-in
> copy of getdate.c, and asked me if I wanted to override the protection
> on getdate.c. I understand why it's doing this.
>
> However, it strikes me that getdate.c is a generated file (after all
> it's made from some combination of its previous self and a yacc file).
> If it's a generated file, why isn't there an entry for it in
> lib/.cvsignore in the distribution? Should I check in the "made" copy
> of getdate.c or the getdate.c that existed before I ran make?
If you are intending to make local changes to some third-party source
and you want to use CVS then you should *NOT* import any of the
"generated" but distributed files into your local CVS repository.
I.e. always run "./configure && make maintainer-clean" prior to running
"cvs import" (if that's possible -- often you'll have to manually clean
out any generated files -- something you'll maybe only find out after
the first build). It is possible to "cvs rm" the generated files after
the import but if you expect to do lots of imports then I'd advise
against this since it makes doing the merges of new releases
unnecessarily harder.
This does mean that you do need to have available all of the tools that
the third-party uses to create the release you're importing, such as
'yacc' for lib/getdate.c, GNU Autoconf for ./configure, etc. and you'll
have to learn to use these tools (hopefully the "vendor" documented
their own build procedures sufficiently that you can do this -- not a
problem with most GNU packages but almost always a problem with anything
and everything else!).
If you are using CVS to *maintain* local changes to someone else's code
then you are a "maintainer" and you should do everything an "original"
maintainer would do (not that the official CVS maintainers are very good
at following this rule with the CVS code itself -- they keep getdate.c
and configure and other generated files in the repository even though
this makes a real maintainer's job harder as you've discovered).
My advice here has been treated as somewhat controversial in the past
but it is based solely on experience (from the well over 300 packages
consising of almost 1.5GB of sources that I've locally maintained). If
you're not planning to do any extensive local changes, or if you can get
away with just keeping little patch files for your local changes, then
you should not use CVS to track third-party code -- it is way over-kill
for the job.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
