Oh, back at my previous employer, we had a branched development tree, and used to merge from the branch into the mainline on a regular basis. After each merge, we would tag the "last version merged into mainline" on the branch, and use that as the base for the cvs update -j the next time around.
The problem was, if one of the files was *deleted* on the branch, cvs tag wouldn't move the tag for that file - you'd have to use cvs rtag for it. The developer in question had done separate "cvs rm"s on the mainline and the branch, but since the deleted version on the branch wasn't tagged, when I did the next merge from the branch to the mainline, the deleted file "reappeared". Anyway, the bottom line was to *carefully* use "cvs rtag".. -----Original Message----- From: Nick Patavalis [mailto:npat@;inaccessnetworks.com] Sent: Wednesday, October 23, 2002 2:13 PM To: Shankar Unni Cc: 'CVS-II Discussion Mailing List' Subject: Re: tag vs rtag question On Wed, Oct 23, 2002 at 01:58:27PM -0700, Shankar Unni wrote: > > 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. > > On the other hand, if you have *deleted* a file, cvs tag won't tag the > repository file. This can lead to interesting "file reappearing in my > workarea" problems when others update to the tag.. Can you elaborate a bit on this? You mean deleted by the developers while working in the branch, or while doing conflict resolution in the trunk? /npat -- Dijkstra probably hates me -- Linus Torvalds, in kernel/sched.c _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
