Re: Merging from vendor-branch to branch

[Nick Patavalis]

On Tue, Oct 22, 2002 at 08:28:43PM -0400, Greg A. Woods wrote:
> > In effect, that after the import a user checking out from the branch
> > might get files from the newer vendor version?
> 
> No, that's one thing that shouldn't happen.  Indeed that's part of the
> problem though -- after an import and merge then the local branch will
> still be stuck with base revisions of locally un-modified files at the
> pre-import level and those files will explicitly have to have their new
> vendor revisions merged to the branch.
> 

I tought that the procedure could be carried out like this. Before
importing the new vendor version (say R2, while the previously
imported one was R1), ask the developers to commit everything. Then
you create a normal branch:

  cvs rtag VENDOR_R2_PREMERGE <module>
  cvs rtag -b -r VENDOR_R2_PREMERGE VENDOR_R2_MERGE <module>
  
You ask the developers to work with the VENDOR_R2_MERGE branch, by
checking out their sources like this:

  cvs co -r VENDOR_R2_MERGE <module or sub-module>

You procceed with the import

  cvs import -m "Imported VENDOR verion R2" <module> VENDOR VENDOR_R2

You merge the local changes

  cvs co -j VENDOR_R1 -j VENDOR_R2 <module>

You resolve the confilicts, test the new sources, and generaly make
sure that everything is stable. Then commit your changes. Several
commits may be necesairy since the conflict resolution may take some
time. No problem though since the rest of the developers are safely
isolated in the VENDOR_R2_MERGE branch). When you have finished with
the conflict resolution and tests you tag the trunk accordingly

  cvs rtag VENDOR_R2_MERGED

Then you ask your developers to commit everything (in the
VENDOR_R2_MERGE branch) and then to merge the branch back to the trunk
(each developer his own submodule).

  cvs co -j VENDOR_R2_MERGE <sub-module>

They will also (the developers) have to resolve the conflicts but
there shouldn't be many since a few changes would have been made since
the branch.

As you can understand the idea is to make a branch that isolates the
developers durring the "turbulent" meging period. Do you see any
drawbacks with this approach?

/npat

-- 
flowchart, n.: The innumerate misleading the illiterate. "A
thousand pictures is worth ten lines of code.
  -- Stan Kelly-Bootle