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

[Dave Korn]

----Original Message----
>From: Mark D. Baushke
>Sent: 22 August 2005 17:04

>>   This reported some conflicts, so I thought I wouldn't merge the new
>> version across to my mainline just yet.  I wanted to see if I had any
>> un-committed changes in my working repository before I started on the
>> merge, so I ran a cvs update command.
> 
> You really need to find a new directory and run the command it suggested
> to resolve conflicts on the top-of-tree.

  I didn't see it suggest any command to resolve conflicts, but to tell the
truth, I was so surprised to see it reporting "conflicts" that I may have
missed it.  I wasn't expecting conflicts, because I had imported some files
to the vendor branch, and hadn't modified anything on the vendor branch, and
was now importing some updates to the vendor branch, and I couldn't imagine
what could have changed for there to be a conflict with.  I didn't know that
it was going to bring my changes across from mainline into the branch and
conflict them with the updates going in on the branch, or whatever it's
done.

  And also, I don't understand how a simple command could resolve a bunch of
conflicts.  AFAIUI there's nothing I can do but go through all 93 files by
hand manually fixing the conflicts, isn't there?
 
> There is a new option in cvs 1.12.x import which is called the -X flag
> to help do things more like you think things should work, but that is not
> really how the older 'cvs import' works.

  Ah, I am on 1.11.17.  Having a look at the -X flag, I can see that's kind
of what I want, but it only affects new files, whereas what I want is for
*all* changes to *only* be made on the vendor branch.

>>   :-( CVS then completely destroyed my entire working repository, giving
>> me a random selection of files, some of which are revisions from the main
>> trunk, and some of which are revisions from the vendor branch.  To be
>> precise, any file that I had made revisions on the main trunk remained on
>> the trunk, but any file I hadn't modified on the main trunk was switched
>> over to the branch.
> 
> The main trunk files are the ones with conflicts that need to be resolved.

  This was the bit I didn't understand.

"  How can there be conflicts on main trunk?  I didn't change those files in
any way.  I only changed the vendor branch.  "

  Or so I thought!

> You could make the mainline be the older kernel version if needed.
> 
>     cvs update -jKERNEL_2_6_12_5 -jKERNEL_2_6_7
> 
> but that is possibly not the right direction for you to take...

  Well, it's _exactly_ the direction I want my working repository to take,
for the moment; I wanted to put off merging the new version across into
mainline until I had a bit more spare time.  That should probably work, but
...
 
>>   What's worse is that CVS has set the HEAD revisions to point to those
>> unmodified files from the vendor branch, so that my HEAD tag now
>> consists of a random set of files from mainline and branch, so there's
>> no way I can see to go back to working on mainline!  Even if I check out
>> a completely new copy of the repository, I will be given this random
>> assortment of mainline and branch versions because that's what the
>> server has marked as current. 
> 
> Yes, well you could checkout the main trunk by time to get a consisten
> state, do a 'cvs tag' to create a nice branch point, and then a 'cvs tag
> - -b' to create a new branch and then finally update your mixed-up tree to
> be on the branch.

  .. this sounds even more like it.  That'll do it nicely, thank you!  If I
had any inkling that "cvs import" would mess with my mainline branch, I
could have just tagged it before the import and sticky-tagged my working
repository to the tag.

>>   What's even worse is that it seems that this insane behaviour is by
>> design.
> 
> It is, but not everyone likes it, which is why the 'cvs import -X'
> feature was created in cvs 1.12.x on 2004-06-26 using code donated by
> Chris Demetriou.
> 
> http://lists.gnu.org/archive/html/bug-cvs/2004-06/msg00173.html
> 
>>   In the "Updating with the import command" section of the "Tracking
>> sources" section of the manual, I see it says
>> 
>> "   For files that have not been modified locally, the newly created
>> revision becomes the head revision.  If you have made local changes,
>> `import' will warn you that you must merge the changes into the main
>> trunk, and tell you to use `checkout -j' to do so: "
>> 
>>   What on earth is going on here?
> 
> You need to do more homework. Locally modified files are on the mainline
> and the default for unmodified files is the top of the vendor branch.

  Yes, I understand that; I was _very_ careful when I was applying patches
not to do any commits on the vendor branch, only on the mainline, because I
thought I'd then be able to import new sources to the vendor branch without
any effort - I thought the work would have to be done when merging the
differences between the two vendor releases across to mainline.

>>   This appears to imply that doing a "cvs import" doesn't just bring a
>> new revision to all the files on the vendor branch, but that in the
>> event of conflicts it will force a partial and broken merge across to
>> your mainline. 
> 
> Yes.
> 
>>   I really can't understand this.  What's the point of having a vendor
>> branch at all if it isn't to isolate changes?
> 
> The vendor branch is not well thought of by a large number of people.
> Welcome to the club.

  Do I get a badge and a sooper-sekritt decoder ring? :-)

>> How can I get my files that I didn't modify on the mainline to go back
>> to r1.1 instead of r1.1.1.2 in my working directory?
> 
> Read the URL posted above for suggestions.

  Thanks... it's too late for the "commit -f" trick now, but I'll remember
it for next time (should I forget to tag the trunk again!)
 
>> How can I get the HEAD tag on those files to point back to the main
>> branch instead of the vendor branch?
> 
> They have always pointed to the vendor branch. You now want to have a
> copy of all of those files as the mainline rather than

  Hey, that sentence was just getting interesting!  However, I think what it
was going to end up saying was "...you want to finish doing the merge",
more-or-less, wasn't it?

> I hope the above thread helps you understand better what is happening.

  Yes, thanks a lot for the reference.

>>   Someone, please help me, or I'm going to have to completely rebuild the
>> whole repository!
> 
> This should not be necessary.
> 
> You may either move forward and make your main trunk consistent with the
> KERNEL_2_6_12_5 import by resolving the conflicts as suggested by the
> cvs import, or you can move backward to make local changes in all of
> your files that moved up to the 1.1.1.2 versions so that your mainline
> reflects the KERNEL_2_6_7 version plus your local changes.

  I still don't know what suggestion you're saying "cvs import" would have
been making, but I imagine it was some kind of "cvs update -j SOMETHING -j
SOMETHINGELSE" isn't it?  If so, then I'd still have to manually fix the
conflicts and commit the fixes, which is just what I was planning to do
anyway.

  Just not straight away!

  In fact I had already checked out a fresh mainline tree in yet another
spare directory and run "cvs update -j KERNEL_2_6_7 -j KERNEL_2_6_12_5", and
it was only when I saw the 93 conflicts roll past that I decided not to
commit any of it for a while.  What I didn't realise was that CVS had
already committed part of it for me!

  Anyway, thanks.  I think you've helped me understand what's going on.  I
suppose the quickest option of all to restore my damaged working repository
would have been to use a date-based rtag command to set a tag just before I
did the import, and then cvs update -rC my working repository to that tag.
In practice, I think I'm just going to knuckle down to it, resolve the
conflicts, and commit it all to mainline.

  Thanks for all the pointers!
    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....