Re: help, doing a CVS import messed up my working dir!?!?!

[Larry Jones]

Dave Korn writes:
> 
>   We're just having a slight semantic disagreement here; to me, a conflict
> is what happens when you try to apply a delta to something that already has
> a (non-identical) delta in the same region, and it doesn't make sense to
> talk about a conflict between files on separate branches; I thought I had
> 1.1 on mainline, and applied a delta that made it 1.2, and I thought I had
> 1.1.1.1 on the vendor branch, and was (by doing the import) effectively
> applying a delta to get 1.1.1.2, and I didn't see how there could be a
> conflict, since both of them were clean deltas to the original source file
> and I never asked it to apply both deltas to the same file!

The key piece of the CVS design philosophy that you're missing is that
the vendor branch *is* the mainline for files that haven't been locally
modified.  When you checkout newly imported files, you get 1.1.1.1 (not
1.1).  It's not until you commit a change that you get a revision on the
trunk (1.2) instead of a revision on the vendor branch.  That makes the
overhead of tracking third-party source files (which was the main reason
CVS was developed in the first place) very small.

>   And to tell the truth, that's all just a matter of wording, but what I
> still don't understand is this:  when cvs complained about a conflict, was
> that because it was applying the 1.1.1.1->1.1.1.2 delta to something that
> already contained 1.1->1.2, or was that because it was applying the 1.1->1.2
> delta to something that already contained 1.1.1.1->1.1.1.2?

Neither.  Any time you have a locally modified file that's also been
modified by the import, CVS will report a "conflict" because there are
*potentially* conflicting changes to the file that have to be resolved. 
Since checkout and update already know how to merge changes, import
doesn't even try but requires you to run a subsequent checkout or update
to merge the changes and discover whether there are any *actual*
conflicts or not.  (In fact, as the manual points out, you need to do
the merge even if there aren't any potential conflicts because that's
what allows CVS to detect and handle removed files.)  In most cases,
there are very few, if any, actual conflicts that have to be resolved
manually before committing the merged changes.

Unfortunately, that does indeed mean, as you discovered the hard way,
that doing an import without doing the subsequent merge, you're
frequently left with a broken trunk.  That apparently wasn't a concern
to the original developers since imports are usually rare and carefully
controlled, but it has become more and more of a problem as time goes
on, which is why the -X flag has been added to import in the new feature
release.  Using it for all imports (typically by adding it to your
.cvsrc file or setting the ImportNewFilesToVendorBranchOnly option in
CVSROOT/config) keeps the trunk isolated from the vendor branch.

I suggest you re-read the section of the manual on tracking third-party
sources, particularly the part about updating with import:

        <http://ximbiot.com/cvs/manual/cvs-1.11.20/cvs_13.html#SEC103>

-Larry Jones

Ha!  Wild zontars couldn't drag that information out of me!  Do your worst!
-- Calvin