On Sun, Oct 07, 2001 at 09:01:31PM -0600, [EMAIL PROTECTED] wrote: > [He has "original" and "changed" source trees for third-party > sources and wants to retroactively put them into CVS] > > OK, no problem (well problems that I have been able to solve) in getting the > original version of the code under CVS.
Do you want the usual vendor-branch setup, with the "original" sources on the vendor branch and your changes on the trunk? To get the original version into CVS, you used "cvs import", right? If "yes" and "no", respectively, go back and do that. > Now to get the changes in I had several thoughts: > > (1) my first thought was just to 'cd' to the 'changed' directory and do > a commit. > (2) more likely, first do a checkout (somewhere), THEN cd to the 'changed' > directory and do the commit. > (3) BUT, I ask does CVS 'need' information in the CVS subdirectories in the > checked out code? It absolutely needs that stuff! Thus, (1) and (2) won't work. > Third thought, and the one I actually tried, tho it > was more work, was to checkout the code, then do a tar->tar to transfer > the files from the changed directory in on top of the checked-out > directory. This gives (leaves?) the CVS subdirectories in place so > it seemed safest. Then did a commit from the top of the checkout > directory. I'd have copied the CVS substructure into "changed", rather than the other way around: # Make a backup of "changed", because we're about to clobber it. # Then: cvs checkout module cd module find . -print | grep '/CVS/' | cpio -pdmu ../changed cd ../changed cvs -nq update # to find out about added/deleted files/directories # do "cvs add"s and "cvs remove"s as appropriate cvs commit The reason for doing it this way is to catch files you've removed or renamed locally. Suppose file "foo" came with the original distribution, but you've removed it. In the CVS sandbox created by the "cvs checkout" step, foo still exists. Now you copy your "changed" tree overtop of the sandbox. At this point, you want foo to be missing, so that you'll know to "cvs remove" it. But in fact, the original version is still in the sandbox. If you copy the CVS admin directories into (a copy of) the "changed" tree, this sort of problem won't occur; *all* differences between "changed" and what's in CVS will be noticed. Locally changed files, and added files and directories, are ok your way; it's only locally deleted or renamed files that are a problem. So if you've already got the following nothing-was-commited problem sorted out already, you don't have to go back and start over. You can instead find out which files were locally removed (for which, "find", "sort", and "comm" are your friends :-), and "cvs remove" them yourself. Renamed files are a problem because a rename is indistinguishable from delete+add. The add part will be ok; the delete part will have the above problem; so you'll end up with copies at both the old and new locations. > Should all (or any) of these work, or only #3? Is there a simpler method? Only #3 (or my variant thereof). No. > For the record, CVS gave me a number of > > cvs commit: Examining src/whatever > > messages, but no indication that it actually did anything (sigh). That should have worked. I'm not sure why it didn't. If the files in "changed" all have *exactly* the same modification timestamps as the "original" revisions created by the import, that would explain it. But that situation strikes me as rather unlikely. Try touching a file you know has changed, and seeing if "cvs commit" now notices the fact. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED] | | / The world has been attacked. The world must respond ... [but] we must be guided by a commitment to do what works in the long run, not by what makes us feel better in the short run. - Jean Chrétien, Prime Minister of Canada _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs