Re: tag vs rtag question
On Wed, Oct 23, 2002 at 01:49:36PM -0500, Todd Denniston wrote: Nick Patavalis wrote: 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 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? The tag will be placed on the most recent revision of the trunk (i.e the HEAD). ...Though I also have some confused ideas about what exactly HEAD means. Could please a CVS guru give us a precise *definition* of what the HEAD tag is? 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. True! /npat -- flowchart, v.: To obfuscate (a problem) with esoteric cartoons. -- Stan Kelly-Bootle ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: tag vs rtag question
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.. Tough call. I used to do merges late in the day when concurrent checkins were unlikely. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
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
RE: tag vs rtag question
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 rms 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
Re: tag vs rtag question
On Wed, Oct 23, 2002 at 02:24:47PM -0700, Shankar Unni wrote: 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 rms 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. Oh, I see. You mean that you were using the *same* tag-name and you were just pushing it forward to more recent revisions, and that this didn't behave well when the push was crossing a delete operation! Tricky, indeed! /npat -- Don't ever think you know what's right for the other person. He might start thinking he knows what's right for you. -- Paul Williams, `Das Energi' ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
