info-cvs
[Top][All Lists]
Advanced

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

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


From: Mark D. Baushke
Subject: Re: help, doing a CVS import messed up my working dir!?!?!
Date: Mon, 22 Aug 2005 09:03:56 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Korn <address@hidden> writes:

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

You really need to find a new directory and run the command it suggested
to resolve conflicts on the top-of-tree.

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.

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

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

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

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

> 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

> I'm utterly confused and bewildered and really really confused as to
> how the import functionality is even supposed to be used.

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

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

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDCfdsCg7APGsDnFERAtEJAKDAC+smQNH1qs997RgVmONqOfY/dACfbARz
t7ur9jOUs0c8QJN+OsD4mgk=
=7zXH
-----END PGP SIGNATURE-----




reply via email to

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