"Schwenk, Jeanie" <[EMAIL PROTECTED]> writes: >Thanks everyone for their responses but I need some additional >clarification.
>1) I checked out all my files prior to the vendors putting the sticky tags >on. We all think the vendor did no such thing. >So why are the sticky tags effecting me? Either you ran "cvs update -r<IForgetWhatYourTagWas>", or you did a "cvs checkout -r<IForgetWhatYourTagWas>". In your first message, you said you created the tag yourself. >2) removing the sticky tags (cvs update -A), does not effect the sticky >tags in the repository just in my local copy? There are no sticky tags in the repository, just tags. There is a sticky tag in your local copy if, after creating the tag in the repository, you ran a "cvs update -r..." or "cvs checkout -r..." as above. A "sticky tag in a local copy" means that, if you run a cvs command from that local copy, there is an implied "-r..." flag even if you don't spefcify one on the command line. Nothing more, nothing less. >3) Do I need to worry about any conflicts because there is a tag and a >sticky tag with identical names? There is only one tag, there can't be a conflict. The tag is in the repository, and it is visible from all local copies (try "cvs status -v <file>"). In your local copy it is visible, and sticky --implied with every CVS command-- until you reset the stickyness with "cvs update -A". >It must not have given the vendors any >warning but it just doesn't seem right to have a tag for release with the >same name as a branch tag. If there is a release tag and a branch tag, they must have different names. Run a "cvs status -v" on one your files and post the output. >[...] >Is it because commit verifies >that the selected files are up to date with the current revision in the >repository? It doesn't make sense that it would be looking at the branch >tags ... doesn't it compare with the trunk from where I originally checked >out? Well, it depends: if your local copy has no sticky tag, "cvs commit" means just "cvs commit"; it checks against the tip of the trunk and tells you to update if someone committed in front of you. If you are up to date, your commit can finish and the contents of your files become the new tip of the trunk. If you have a sticky *branch* tag, "cvs commit" really means "cvs commit -rBRANCH_TAG", so it checks against the tip of the branch named by BRANCH_TAG. If someone committed to the branch before you did, you will be told to update. Your "cvs update" will mean "cvs update -rBRANCH_TAG" and you will be brought up to date with the tip of the branch. If you are up to date, your commit can finish and, because of the implied "-rBRANCH_TAG", the contents of your files become the new tip of the branch. If you have a sticky *release* tag (which is the pickle you're in), then "cvs commit" means "cvs commit -rRELEASE_TAG", so it checks that nobody committed to RELEASE_TAG while you weren't looking. Of course nobody did, it's impossible. Therefore your files are up to date, and the commit proceeds to the next step... which is impossible. Just do a "cvs update -A". It will unstick your local copy and do strictly nothing to the repository. You'll like the result. -- Pierre Asselin Westminster, Colorado -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =----- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
