Re: how to undo import

[Kevin Rodgers]

Pierre Asselin wrote:
>>Kevin Rodgers wrote:
>>
>>>I'm trying (for the first time) to track a large 3rd party distribution.
>>>So of course I screwed it up: I unzip'ed the distribution in the working
>>>directory itself and then imported it, which resulted in all the CVS
>>>subdirectories being imported into the repository.
>
> Are you sure ?  The CVS subdirectories should be ignored by default.
> Still, it's probably a good idea to undo the import.

Well I seem to remember a bunch of messages like

I foo/bar/CVS

> First, back up your repository.

Done.  (Love those Network Appliance snapshots!)

> Check out a temporary working copy somewhere else.  Don't worry
> about conflicts from the second import, just do a plain checkout
> to get a working copy.
>
> Use "cvs status -v" file by file to find the revision numbers associated
> to SAXON_B_8_3 and SAXON_B_8_4.
>     *)  For files where the two tags are present and are the same,
>    just delete the SAXON_B_8_4 tag.
>        cvs tag -d SAXON_B_8_4 some_file
>     *)  For files where the two tags are present and are different,
>    delete the bad revision and bad tag.  This is a little
>    tricky because the revision you want to delete is often
>    the one checked out in your temporary working copy.  The
>    following should work:
>        cvs update -r SAXON_B_8_3 some_file
>        cvs admin -o<bad_revnumber> some_file
>        cvs tag -d SAXON_B_8_4 some_file
>        cvs update -A some_file
>    where <bad_revnumber> is the revision number of SAXON_B_8_4.
>    I'm pretty sure you have to give it numerically instead of
>    using the tag, but you can try that too.
>     *)  For files with only SAXON_B_8_4, go delete the ,v file
>    in the repository.
>     *)  For files with only SAXON_B_8_3, do nothing.
>
> Needless to say, be very careful not to mix files, revision numbers
> and tags on those command lines.
>
> Now wipe out the temporary working copy.
>
> Check out a working copy again.  It should be identical to what
> you had before the bad import.  Leave that working copy aside.
> Go unzip somewhere else and re-import your freshly unzipped copy.

Ouch, that looks like a lot of work.  Since my local changes to the
previous version were incorporated into the new distribution by the
author, I am just going to start over with SAXON_B_8_4.  I can't believe
CVS doesn't have a simple command to undo this, something like

cvs undo -jSAXON_B_8_4 public/3rdParty/java/saxon

After all, there aren't any changes subsequent to that tag that could
complicate matters.

>>>Further, I had
>>>committed a local change to a few files (including some binary files) in
>>>the original distribution, so the import complained about conflicts and
>
> That's normal.
>
>>>I followed its advice to checkout the original version of the
>>>distribution.
>
> That's not quite what it says, but your checkout command
>
>>>cvs checkout -jSAXON_B_8_3 -jSAXON_B_8_4 public/3rdParty/java/saxon
>
> is correct, provided you first go to an empty directory.

But I didn't, I was still in the directory from which the
public/3rdParty/java/saxon working directory is accessed.  (How was I
supposed to know to change to an empty directory?)

> Edit the text files to resolve the conflicts.  For the binary files,
> work it out.  CVS can't help you there besides providing you with
> copies of the old, your changed version, and the new.
>
> When all the conflicts are resolved, commit.

Thanks for taking the time to write such a detailed response.  But I'm
more likely to make another mistake if I follow your instructions, so I
don't think I should attempt this operation after all.

--
Kevin Rodgers