Nick Patavalis wrote: > <SNIP> > 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 > <SNIP> I have not worked with normal branches or rtag before, I have always used tag and import, so I am asking this from a 'please correct my head perspective'.
If at the point the rtag is ran above the last commit of a file happened on the branch would rtag place the tag on the HEAD version of the file (what we want here, I think) or on the branch version of the file? http://www.cvshome.org/docs/manual/cvs_4.html#SEC44 http://www.cvshome.org/docs/manual/cvs_17.html#SEC153 The above pages from the manual are not real clear (to me) on what rtag tags if you do not give a -r<somthing> as it is working on some (possibly unknown) state of the repository. Even -D seems a little scary unless you have spent enough time looking in the repository to verify that, at the time specified, the baseline is consistent. I would think that with the situation above, doing a cvs tag VENDOR_R2_MERGED in the working directory where conflict resolution was finished would be the safest method, to be sure you tagged the resolved files and not something else. Thanks for any clue sticks. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs