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
RE: Dumb question about 'cvs import' of 3rd party products...
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 / 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
Re: Dumb question about 'cvs import' of 3rd party products...
Masterson, David writes: > > 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 / > cvs checkout -jPROD2 product That might work for release 2, but it wouldn't work for subsequent releases. It's better to always specify both tags: cd release1 cvs import -m "Import release 1" product VENDOR PROD1 ... time passes ... cd release2 cvs import -m "Import release 2" product VENDOR PROD2 cd / cvs checkout -j PROD1 -j PROD2 product cd product cvs commit -m'merge changes' Then for the next release you'd use ``-j PROD2 -j PROD3'', etc. -Larry Jones That's one of the remarkable things about life. It's never so bad that it can't get worse. -- Calvin
RE: Dumb question about 'cvs import' of 3rd party products...
Dumb question #2: After having done a number of "imports", is there a simple command to get a list of vendor and release tags (along with when they were created)? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, July 07, 2000 2:17 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Dumb question about 'cvs import' of 3rd party products... Masterson, David writes: > > 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 / > cvs checkout -jPROD2 product That might work for release 2, but it wouldn't work for subsequent releases. It's better to always specify both tags: cd release1 cvs import -m "Import release 1" product VENDOR PROD1 ... time passes ... cd release2 cvs import -m "Import release 2" product VENDOR PROD2 cd / cvs checkout -j PROD1 -j PROD2 product cd product cvs commit -m'merge changes' Then for the next release you'd use ``-j PROD2 -j PROD3'', etc. -Larry Jones That's one of the remarkable things about life. It's never so bad that it can't get worse. -- Calvin
Re: Dumb question about 'cvs import' of 3rd party products...
Masterson, David writes: > > After having done a number of "imports", is there a simple command to get a > list of vendor and release tags (along with when they were created)? Not really -- as far as CVS is concerned, vendor and release tags are just tags, it doesn't keep track of them specially. And it doesn't keep track of when a tag is created or even when it's applied to a particular file. Within a checked-out module, you can use ``cvs status -v'' to find all the tags on a particular file, which is usually all you need if you use some consistent naming scheme -- the vendor tag will always be a branch tag and the release tags will be revision tags. -Larry Jones It seems like once people grow up, they have no idea what's cool. -- Calvin
