Re: problems importing into a branch

[Pierre Asselin]

> I think I am confused between the branch tags and the vendor tags
> required by the cvs import command.  Anybody have a clear explanation
> of how to do this operation?

Yeah, it's tricky.  I did something similar a while ago;  let's see if
I can remember.

Think of the vendor branches as belonging to someone else.  You use them
ONLY to hold code received from others, and you store the code EXACTLY
as received.  The vendor branches are distinct from your own development
branches and from your trunk.

Two warnings:
1) This is somewhat tricky.  Make sure you understand what I say
   before you jump in.  Uh, and wait for the list to comment in case
   I make a mistake...
2) Some files will end up with interesting revision numbers,
   like `1.1.1.1.2.3'.  DON'T TRY TO FIX THEM.  They aren't broken
   and they are CVS' business, not yours.  Just thought I'd mention
   that.


> (I am trying to stuff an existing system into CVS.  First I import the 
> current production code,

The usual, then.

    $ cd clean-production-tree
    $ cvs import -m'production' some/where PRODUCTION prodgroup_0


> then I create a branch for development.  I want to 
> import the existing development code to update the development 
> branch.

I don't think you can import to a branch like that, but you can import
to a separate vendor branch.

    $ cd clean-devel-tree
    $ cvs import -m'development' -b 1.1.3 some/where DEVEL develgroup_0


>  After some additional changes I plan to merge the development 
> branch back to the main trunk.)

OK, let's see how to work this out.  First, checkout the main tree.

    $ cvs checkout <modulename>
    $ cd <modulename>

Create your development branch and update to it.

    $ cvs tag devel-bp
    $ cvs tag -b devel
    $ cvs update -rdevel

Merge the development tree you imported.

    $ cvs update -jDEVEL
    <fix conflicts, there shouldn't be any>
    $ cvs commit
    $ cvs tag devel_0

At this point, the code on your `devel' branch should be identical
to the `develgroup_0' release you imported on the DEVEL vendor branch.

>  After some additional changes I plan to merge the development 
> branch back to the main trunk.)

OK, work some more on your devel branch.

    <make the changes>
    $ cvs commit
    $ cvs tag devel_1

Merge to the trunk and plant a moving tag to remember how far you've merged.

    $ cvs update -A
    $ cvs update -jdevel-bp -jdevel_1
    <fix conflicts>
    $ cvs commit
    $ cvs tag prod_1
    $ cvs tag -f -rdevel_1 devel_MERGED_TO_TRUNK

=======
What about the vendor branches?  Hopefully you can just forget them.
You will only need them if your friendly colleagues throw you a knuckleball.

  ``Hey, Andy, we've made these changes to the production tree while
    you weren't looking.''  

Solution: reimport to the regular vendor branch and merge to your trunk.

    $ cd new-clean-production-tree
    $ cvs import -m'production updates' some/where PRODUCTION prodgroup_1

    $ cd <your old sandbox, which was left at the tip of the trunk>
    $ cvs update -jprodgroup_0 -jprodgroup_1
    <fix conflicts>
    $ cvs commit
    $ cvs tag prod_2


  ``Hey, Andy, we did this to the development tree while you were busy.''

Solution: reimport to the second vendor branch and merge to your
development branch.

    $ cd new-clean-development-tree
    $ cvs import -m'development' -b 1.1.3 some/where DEVEL develgroup_1

    $ cd <your old sandbox>
    $ cvs update -rdevel
    $ cvs update -jdevelgroup_0 -jdevelgroup_1
    <fix conflicts>
    $ cvs commit
    $ cvs tag devel_2

Then you probably want to merge that stuff back to the trunk too.

    $ cvs update -A
    $ cvs update -jdevel_MERGED_TO_TRUNK -jdevel_2
    <fix conflicts>
    $ cvs commit
    $ cvs tag prod_3
    $ cvs tag -f -rdevel_2 devel_MERGED_TO_TRUNK

That's what the vendor branches are for:  to follow sources received
externally.  Since this is your code, you shouldn't need the vendor
branches after the initial imports.