Re: How to do this...

[Eric Siegerman]

On Sun, Oct 07, 2001 at 09:01:31PM -0600, address@hidden 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.        address@hidden
|  |  /
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