I think I see now. I couldn't quite gather in the purpose of the "checkout"
in the discussion with "import" -- particularly with *two* tag names
mentioned. Now that I look at it, would the proper way of doing the import
of release 2 be:
cd release2
cvs import -m "Import release 2" product VENDOR PROD2
cd /<workdir>
cvs checkout -jPROD2 product
CVS would then workout that the ancestor of PROD2 is the first release and
merge between the two?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 07, 2000 1:37 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Dumb question about 'cvs import' of 3rd party products...
Masterson, David writes:
>
> For instance, assume a 3rd party product consisting of a single directory
of
> source code. In release 1 of the product, the directory contains two
source
> files (x.c and y.c). In release 2 of the product, the developer has
removed
> y.c and added z.c. If you simply "cvs import" release 2 of the product on
> top of release 1, you will wind up with a directory that has three source
> files (x.c, y.c, and z.c).
If you do a merge checkout like CVS suggest when there are conflicts
(CVS suggests doing ``cvs checkout -j FOO:yesterday -j FOO foo'', but
that doesn't work if you do multiple imports in a single day so it's
really better to use the import tags), it will delete files that are no
longer relevant. Committing the result then updates the repository.
-Larry Jones
TIME?! I just finished the first problem! -- Calvin
