Problems tagging and checking in files into cvs (Sticky tags)

Question

Hi guys,

I am having some trouble with checkout out files using a release tag and hope someone here can help.

Basically my repository is structured like this

module1
 - src
 - jsp
 - conf

module2
 - src
 - jsp
 - conf

A release can include changes in either module1 or module2 or both. There are several developers that could be working on any files in any of the modules.

To work on a new release, we checkout the latest release (e.g. LIVE-REL-2.4) using the following command

cvs checkout –r “LIVE-REL-2.4” moduleName

Note that we dont check out from trunc. The reason for this is that if you checkout from trunc you are including files which other developers have checked in but you dont want to include in the next release.

After we've checked out the latest release, we make the changes and check back in the new files. For the delivery, we label all the new files we've checked in with a bug specific tag.

cvs tag BUG434 <file1> 
cvs tag BUG435 <file2>

We then apply a new label to every file that is on the current release.

cvs tag – r “LIVE-REL-2.4” “LIVE-REL-2.5”

We then add the new release tag for the new files we've checked in

cvs tag –r “BUG434” “LIVE-REL-2.5”
cvs tag –r “BIG435” “LIVE-REL-2.5”

The above ensures that the new release will include all the files from the "latest delivered release" plus bug fixes that we want to include in the release. To checkout the new release we just do this

cvs checkout –r “LIVE-REL-2.5” moduleName

The checkout from the above is build tested and delivered. There is though a bit of a confusion as to whether this process actually work. We've suddenly had people complain that they cant check in any new files if they check out by tag. The error that is generated is shown below

sticky tag `LIVE-REL-2.5' for file `DatabaseFacade.java' is not a branch

I have been doing some reading on this error but i havent been able to find a solution to it. From what i gather from googling around, the solutions available are as follows

• run "cvs update -A" on these files to revert the working copy to the head.

This wouldnt work for me because i dont want to release the changes that are on the "head". The revision that i want to release is an updated version from the previous release. The one on the 'HEAD' could be one that someone has updated and is not to be release for the next 3 release.

• The tag needs to be made into a branch

I wish i can do this but i cant seem to be able to convince any of my bosses that we should support branching. We dont support it because it apparently makes things a lot more complicated than they need to be.

• Prevent people from checking in files that are not ready to be delivered in the next release.

This might work as i would then be able to just checkout from 'HEAD' everytime there is a new release.

Now my questions really are as follows,

• Is there some way i can checkout using the above procedure without coming across the "sticky tag is not a branch" error?
• Is there a better way i can achieve the same steps above without having to use branching?
• This sounds to like its one of the most common situations in a development environment. How do other people do it without using branching?
• And finally if you have any knowledge of subversion, do you know if it works the same way and i will have the same problems if i change to subversion?

Any help will be greatly appreciated.

Answer 1

The natural solution to your problem is branching. However if you have this scenario infrequently and are determined to avoid branches, you can put all your versions on the HEAD and set the tags accordingly.

Lets say you have the following version of DatabaseFacade.java:

1.1: original version, which has the bug
1.2: version with new feature, which you do not want to release yet

You checked out 1.1 and made your bug fix, but - alas - you can't commit it because you are on a sticky tag. To solve it, do the following (I didn't test the code, but it should illustrate the idea):

# backup file with fixes
mv DatabaseFacade.java DatabaseFacade.java-fixed

# revert to HEAD: remove the sticky-ness
cvs update -A DatabaseFacade.java

# get revision 1.1 (non sticky)
cvs update -p -r1.1 DatabaseFacade.java > DatabaseFacade.java

# commit it
cvs ci -m "reverted to revision 1.1." DatabaseFacade.java

# commit your file with fixes
mv DatabaseFacade.java-fixed DatabaseFacade.java
cvs ci -m "fixed BUG434" DatabaseFacade.java

# restore the latest development version to HEAD
cvs update -p -r1.2 DatabaseFacade.java > DatabaseFacade.java
cvs ci -m "reverted to revision 1.2." DatabaseFacade.java

# also fix the bug in the latest development version
cvs ci -m "fixed BUG434" DatabaseFacade.java

So now DatabaseFacade.java will have the following versions:

1.1: original version, which has the bug
1.2: version with new feature, which you do not want to release yet
1.3: same as 1.1
1.4: your bugfix to 1.1
1.5: same as 1.2
1.6: version with new feature and bugfix

Now you can tag revision 1.4 for the new release:

cvs tag -r 1.4 LIVE-REL-2.5 DatabaseFacade.java

When you take this approach, you should make sure that none of your fellow developers runs a cvs update while you are "playing with the history", i.e. while either 1.3 or 1.4 is the latest on the HEAD.

---

There is no benefit in switching to Subversion. It will not help you with these kind of problems. If you are seriously considering a different version management system, you should take a look at Mercurial or any other Distributed Versionmanagement System. In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.

---

By the way: Since you are tagging your new files with bug-identifier-tags (e.g. "BUG434"), you might also want to tag any existing file related to that bugfix with the same tag.