Re: sticky tag Y for file X is not a branch

[Jim Hyslop]

Paul Summermatter wrote:
> All,
>
>     I'm not sure how I got into this situation, but I could  desperately 
> use some help getting myself out of it.
> [...]>
> 9-padua% cvs commit -m "Test Checkin"  
> UnlimitedHedgeReportController_FuturesandCINComments.java
> Warning: No xauth data; using fake authentication data for X11  forwarding.
> cvs server: sticky tag `V00-FR7_3_0_5_39' for file  
> `UnlimitedHedgeReportController_FuturesandCINComments.java' is not a  
> branch
> cvs [server aborted]: correct above errors first!

[...]
>     I am not a cvs internals expert, but I noted that the Sticky Tag  
> line above does not say (branch: 1.2.2.1) but says (revision:  
> 1.2.2.1).  How cvs determines whether the file is on a branch tag or  
> not is the crux of my problem.

A file is on a branch tag if the tag used to check it out was a branch 
tag. In other words, for the command 'cvs [update or checkout] -r TAG', 
if TAG was created by using the -b option, then the file will be on a 
branch, otherwise it will be a revision tag.

Tags are maintained on a file-by-file basis. This means that one file 
could have the tag as a branch tag, and another as a revision tag, and a 
third file might not have the tag at all. So the above checkout command 
could easily result in one file being on a branch and another on a 
revision tag.

> ===================================================================
> File: TradeItemHR.java  Status: Up-to-date
>
>    Working revision:    1.4.2.1
>    Repository revision: 1.4.2.1 /opt/cvsroot/V3/ICTS/src/com/ 
> tradecapture/icts/reporting/control/common/unlimitedhedgereport/ 
> TradeItemHR.java,v
>    Sticky Tag:          V00-FR7_3_0_5_39 (branch: 1.4.2)

Two separate tag commands must have been issued, one specifying the -b 
option for TradeItemHR.java, and the other omitting it for 
Unlimited[...]Comments.java.

> "Scenario3:
>
> If you made the same mistake as in Scenario2 (of placing a non-branch  
> tag where you wanted a branch tag), but really want <oldtag> to be  the 
> name of your branch, you can execute a slightly different series  of 
> commands to rename it and move your working directory onto the  branch.
>
> Warning: This is not a way to rename a branch tag. It is a way to  turn 
> a non-branch tag into a branch tag with the same name.
>
>                     cvs rtag -r <oldtag> <branch_point_tag> <module>
>                     cvs rtag -d <oldtag> <module>
>                     cvs rtag -b -r <branch_point_tag> <oldtag>  <module>"
>
>     When I look a the top of the file of one of the problem files on  
> the cvs server itself, I can't see why cvs doesn't recognize that the  
> file is tagged with a branch tag.  When I compare this file with  other 
> files that are not having a problem, I can't see a an obvious  
> difference.  Here is the top of  
> UnlimitedHedgeReportController_FuturesandCINComments.java,v:

Generally, you should stay away from the repository until you are an 
expert (now that you're curious, though, a branch tag will have a 0 as 
the second-last number, e.g. TAG_NAME:1.2.0.2 - if you peek at 
TradeItemHR.java,v you'll see that the revision will be 1.4.0.2).

An easier way to get this information is to use 'cvs status -v'. If you 
issue it for the two files in question, you'll likely see that one says 
"(revision: 1.2.2.1)" and the other says "(branch: 1.2.2)"

To correct this problem, use a slight modification of the procedure you 
found above on the files that indicate the tag is a revision, and *only* 
on those files. Use 'tag' instead of 'rtag', and list the affected files 
on each command, e.g.:

cvs tag -r V00-FR7_3_0_5_39 V00-FR7_3_0_5_39_base [list of affected files]
cvs tag -d V00-FR7_3_0_5_39 [list of affected files]
cvs tag -rV00-FR7_3_0_5_39_base -b V00-FR7_3_0_5_39 [list of affected files]

To prevent this problem from recurring, adopt the following conventions 
and procedures:

1) Adopt a naming convention that requires all branch tags to have 
something that identifies them as branch tags. I find the suffix "-bt" 
works well.

2) Adopt the following procedures when creating a branch tag:
- use 'cvs tag tagname' to mark the base of the branch
- use 'cvs tag -b tagname-bt' to create the branch itself.
Note that the base of the branch uses the same tag name, without the -bt 
suffix.

Most importantly: watch for any error messages in either tag command, 
especially messages like "tag exists". DO NOT PROCEED until those errors 
have been fixed.

--
Jim