[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cannot committ ... sticky tags

From: Pierre Asselin
Subject: Re: cannot committ ... sticky tags
Date: 9 Jan 2002 21:00:17 -0600

"Schwenk, Jeanie" <address@hidden> writes:

>Thanks everyone for their responses but I need some additional

>1)  I checked out all my files prior to the vendors putting the sticky tags

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

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

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

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 =----- - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

reply via email to

[Prev in Thread] Current Thread [Next in Thread]