info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vendor/local files in CVS


From: Bob Fyfe
Subject: Re: vendor/local files in CVS
Date: Tue, 22 Feb 2005 16:56:57 -0500

At 12:55 AM +0000 2/22/05, Pierre Asselin wrote:
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.

Yes,  I know that. I was just trying to be succinct.  I understood the
flow up to this point.  Most of how I've used CVS however has been
development from the ground floor and was unsure of re-merging in
vendor code.


 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.

This is a good warning. In my travels I have only ever done one import, the
initial one into the project. So I was unaware that you could re-import but now I see how that
works.

I confess though, I am still a bit nervous about doing the merge. :-)

bob



--
pa at panix dot com
_______________________________________________
Info-cvs mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/info-cvs


--
*****************************************************************
*Bob Fyfe,      KG8FU,  NREMT-P "A King's Kid" John 1.12      *
*****************************************************************
*Phone:        (419) 372-2103                                           *
*Internet: address@hidden * *U.S.Post: c/o Information Technology Services *
*                Rm.254 Hayes, BGSU                                     *
*                Bowling Green, OH 43403                                *
*****************************************************************




reply via email to

[Prev in Thread] Current Thread [Next in Thread]