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
_______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
