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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
