Re: vendor/local files in CVS

[Pierre Asselin]

Bob Fyfe <address@hidden> wrote:

> We receive source code from a vendor which consists of many files 
> (call it version 1).

Ok so far.

> That source code requires running a 'make' to 
> set up the environment from the tar file they distribute.

Fine, but the 'make' has nothing to do with CVS.

> Subsequently, several files have been changed. Additionally, several 
> files have been created.  So at this point you have "vendor" source 
> files and several "localized" files (i.e. vendor files modified and 
> new locally created files).

Still ok, this is a fairly routine use of CVS.

> This would be an easy scenario to put 
> things into CVS - you could just put all of it, vendor and locally 
> modified files there.

Not like that.  There are several steps.
    1)  Import ONLY the vendor files into CVS.
    2)  Check out a sandbox.
    3)  Work in the sandbox.  Change files, add new files,
        run make.
    3b) Do *not* run "cvs add" on the products of the make.
        Those are generated files and it is best to manage
        only source files.
    4)  Commit the changes in the sandbox.


> The problem I am trying to conceptualize 
> before it happens is when the vendor provides a new release with new 
> vendor source files and new versions of the locally modified set of 
> files.

You tag your trunk, import the newly received files, and merge
the import to the trunk.
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_13.html#SEC103

This takes a bit of getting used to.  It's important to understand
that each import after the first *breaks the trunk* until the merge
has been successfully committed.  Sometimes the vendor changes don't
merge cleanly, so it is a good idea to tag the trunk before importing.
Having a tag allows you to recover your last good copy while someone
figures out how to finish the merge.  In extreme cases you can
branch from the last good trunk point and continue working
as if the import hadn't been done.


-- 
pa at panix dot com