info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave Korn
Subject: help, doing a CVS import messed up my working dir!?!?!
Date: Mon, 22 Aug 2005 12:16:13 +0100


    Hello everyone, 

  I think I must not understand how "cvs import" is meant to work after all.
Here's what I did:

-> Import a set of linux kernel sources following the "First import"
instructions from the manual

<untar in spare dir>
cd linux-2.6.7
cvs import armtools/linux KERNEL_ORG KERNEL_2_6_7

-> Check myself out a working copy of the new repository in a different
directory:

cd /repository
cvs co armtools
cd armtools/linux

-> Applied some patches and edited a few files in the working copy and
committed them, getting revisions like 1.1 -> 1.2 -> 1.3 -> 1.4 ...

  So far so good.  Here's where it all goes wrong: I decided to import a
more recent version of the kernel:

<untar in spare dir>
cd linux-2.6.12.5
cvs import armtools/linux KERNEL_ORG KERNEL_2_6_12_5

  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.

  :-( 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.

  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.


  What's even worse is that it seems that this insane behaviour is by
design.

  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?

  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.

  I really can't understand this.  What's the point of having a vendor
branch at all if it isn't to isolate changes?  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?  How can I get the HEAD tag on those files to point back
to the main branch instead of the vendor branch?  I'm utterly confused and
bewildered and really really confused as to how the import functionality is
even supposed to be used.

  Someone, please help me, or I'm going to have to completely rebuild the
whole repository!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....





reply via email to

[Prev in Thread] Current Thread [Next in Thread]