First, I have to admit I screwed up a little with CVS. I had a release tag releaseX
, which was done some time back (i.e., not HEAD). Then I decided I need a maintenance branch at that point. Instead of creating a branch tag (branchX
) in addition to releaseX
, I deleted the release tag and created a branch tag (erroneously) named releaseX
. I then proceeded to work on that maintenance branch, and created releaseX1
, releaseX2
etc.
My problem: when I check out releaseX
, I get the branch head, i.e. the latest code from that branch. What I need now is the code at the branch point, i.e. the former releaseX
code.
Is there any way to do this?
Reverting to earlier repository version from backup is not an option.
Edit: I know I can work around it by doing a date-based checkout. I would like to know if it's possible to still do a tag-based one.
Update (Re @Philip Derbeko): I know that CVS does not correlate between files. But CVS does have the information where the branch occured. In ViewVC, I can even see it:
File X - Revision 1.y - Branch: MAIN - Branch point for: releaseX
The next file revision is:
File X - Revision 1.y.2.1 - Branch: releaseX - CVS Tags: releaseX1
The metadata is apparently there. Hence my question: Is it possible to check out the branch point, not the branch HEAD?
Since you did not set a tag when branching, the only way I see, is to use the date approach. But you can still set that tag now. Lets assume you want to call that initial release "ReleaseX0", because unfortunately the name "ReleaseX" is already occupied for the branch. Depending on whether you want to set the tag on the branch or on the MAIN branch you can use either of these checkout commands:
Then set the tag:
From now on you can checkout this release in the same way as you checkout the other releases.
As you pointed out in your comment to my initial response, renaming the branch from releaseX to releaseX_branch like this does not work:
To rename a branch "cvs admin -N < old >:< new >" needs to be used. But renaming a branch is a bad idea anyway. (I am sorry for bringing it up in the first place ;-).), Renaming will mess up the working copies of other users. So it is probably best to stick with the original name.
I'm not a CVS expert. Here's what I would do if I were in your place. CVS marks file versions in HEAD branch as 1.N, when you branch file at version X, commits to that branch get marked as 1.X.B.M . So after checking out releaseX, I would write a script that would update files that were changed in branch to a version 1.X, and then tag my working copy. Maybe there is a simpler way, but I don't know about it.
Sorry, can't be done. The only option you have is doing time-based checkout. The problem is that CVS does not correlated between different files, which is done using tags. Once the tag is gone, the information that ties different files together is gone forever. Meaning that you have to write a script finding the branch point for every file.
As a general practice and in case you don't care for many tags in repository, I would suggest to create a tag on the trunk (or a branch from where you are branching) and on merge as well. Those tags should follow naming convention and then in CVS scripts you can prevent messing with them.
With CVS you should automate as much as possible :)
This comes four years later - it won't help you out, but it may help someone like myself trying to figure this problem out via google. I recently ran across the same problem with a merge that I am doing. I need to see the parent ancestor of files between the branch head and mainline head - which is the branch point. The branch point was not tagged and was created years ago - at an indeterminate time so tagging by time is no help.
The solution I came up with is figuring out the branch point revision number for each file and applying a branch point tag via a PERL script. It is very similar to what is pointed out here: http://www.cvsnt.org/pipermail/cvsnt/2006-February/024063.html
A little CVS background: In CVS branches are kept track of by adding a .0.x to the mainline revision of the file. For example if the mainline revision is 1.18, then a branch off of that will be 1.18.0.x, X the branch number (if there were already a branch in existence from this revision number then x would be 2 -> 1.18.0.2). The ".0" is dropped when you revise files on the branch so the branch will be 1.18.0.2 in this example and the first revision will be 1.18.2.1 and the second revision will be 1.18.2.2. A lot of this is drawn from this: http://www.astro.princeton.edu/~rhl/cvs-branches.html#branchnumbers
I found a perl script here: https://github.com/effectiveprogramming/ep-cvs/wiki/List-CVS-Tags that will either list the CVS tags when given the -t switch or if given a branch name tag it will list all files and revision associated with that tag. This script uses this command: "cvs -q status -R -v filename" which will list the branches with the ".0" part hidden, so you simply remove the ".x" from the revision number of the desired branch name. So I took the script on github and added a few lines. You simply execute this script with a branch name as an argument and it will tag the branch point with the same branch name with an _BP appended to it.