Kevin Rodgers <[EMAIL PROTECTED]> wrote:
> Should I infer from the complete lack of responses over the last 5 days
> that my only option is to delete the distribution directory in the
> repository itself, and start over with the current version?
That may be, or possibly the original question wasn't clear. :-)
> 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.
First, back up your repository.
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.
> > 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.
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.
--
pa at panix dot com
_______________________________________________
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
