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

[Mark D. Baushke]

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

Dave Korn <address@hidden> writes:

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

I should have suggested something like this:

   cvs update -jKERNEL_ORG:yesterday -jKERNEL_2_6_12_5

at the end of the 'cvs import' command.

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

All of the conflicts are a result of your commits to the mainline of
changes to previously imported KERNEL_ORG files.

> > 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 1.11.x does not have this feature, so you will want to consider
using the script that Chris posted. However, that is mostly for handling
fresh imports of code. For now, you will probably need to move ahead and
make the mainline your very own...

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

Well, now you know.

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

Okay.

> >>   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!)

Okay.

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

Either finish doing the merge now, or just go back and make and force a
mainline commit of all of the 1.1.1.1 version files so that they become
the mainline version you want. Leave any of your locally modified files
alone.

Later, you can do the checkout of the mainline trunk and merge
   
   cvs update -jKERNEL_2_6_7 -jKERNEL_2_6_12_5

to put all of the new kernel files into the main trunk for your use.

It does not really matter when you do what on your mainline.

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

As it does not know the label you used last, it will suggest

   cvs update -jVENDOR:yesterday -jVENDOR_TAG

based on your 'cvs import module VENDOR VENDOR_TAG' import if there were any
local modifications on the mainline from the VENDOR version.

You may use

  cvs update -jKERNEL_ORG:yesterday -jKERNEL_2_6_12_5

or

  cvs update -jKERNEL_2_6_7 -jKERNEL_2_6_12_5

right now to do what cvs wants for you to do in order to resolve the
'conflicts' it believes it has noticed.

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

Yup.

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

Well, I would avoid the -C flag if it were me.

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


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

iD8DBQFDCgStCg7APGsDnFERAhUuAJ0bixU3XuQ5cHh1qw/c3MuBU16BIwCfZcTe
CagLEQdt0nRhjdf32rD6nEA=
=S1l5
-----END PGP SIGNATURE-----