The CVS commands here assume that you are using the command line version of CVS. Tips and tricks for a specific CVS GUI are specific to each GUI and do not really belong here.
Viewing the commit log of a file.
$ cvs log filename |
Show current status of a file.
The status command will show you the latest version, the version in your working directory and if your local copy has been modified.
$ cvs status filename |
Performing a CVS diff
After developers have checked in updates to the code it may be beneficial to see what has changed, either to help solve bugs or to track changes. There are several option to do this.
Perform a diff between complete branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 |
Perform a diff between a single file in two branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 filename |
Perform a diff between different versions of a file:
$ cvs -q diff -u -r version1 -r version2 filename |
Perform a diff between working version and most up to date file in database:
$ cvs -q diff -u filename |
Perform a diff between working version and a specific database version:
$ cvs -q diff -u -r version filename |
Retrieving CVS Information on Files
To retrieve the current version and other relevant information about a file run:
$ cvs status filename |
To retrieve the entire change log pertaining to a file run:
$ cvs log filename |
Retrieving CVS Files Based Upon Revision
To retrieve a file from CVS based upon a revision number perform the following:
$ cvs -q up -Pd -r revision filename |
To get the revision number use the log command above
Tag file in CVS as a Release
To tag files in CVS as a release perform the following:
$ cvs tag |
Run the command from within the release source dir.
Creating a Branch
I like to do the following before creating a branch:
See what tags are available and pick one.
$ cvs -q log filename |
Revert to a tagged version of HEAD.
$ cvs -q up -r TAG_Version |
To create a branch in CVS perform the following:
$ cvs tag -b |
Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_36_BUG_.
cvs -q up -r |
$ cvs -q status <-- confirm that the branch has specified as the tag |
$ cvs tag _mm_day_year <-- eg: BRANCH_12_BUG_12345_07_17_2009 |
Reverting to a Branch
To revert to a branch in CVS perform the following:
$ cvs -q up -r |
Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_BUG_.
Verifying you are in a branch
To verify you are in a branch
$ cvs -q status |
You will see that the branch is a sticky tag.
Merge Current Branch with HEAD
Ensure that you are in the branch by reverting to the branch and Verifying that you are in the branch.
$ cvs update -j |
This will ensure that you are your branch is getting merged properly with HEAD so the only differences you see between your branch and the are changes that you made. You can verify this from your branch with:
$ cvs -q diff -u -r | less |
You will eventually have to commit your changes you should always do a tag on the branch after your commit.
$ cvs tag |
Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option
$ cvs update -j -j |
This command will unfortunenately result in a lot of your ID tags getting changed at the top. Using the --kk option will avoid this problem. But then you won't see which files have changed and You won't know who last modified a file easily. After you run this command I recommend:
$ vim `cvs up -d | grep '^C' | sed -e 's/^C //'`
You may find the following page interesting as well: http://kb.wisc.edu/middleware/page.php?id=4087
This will grab all of the conflicting files. You can save them with :w. And step through them with :bn. You can easily close them all with :wq!.
Merge HEAD into Current Branch Multiple Times (with tags)
To merge current HEAD into a branch that has already had HEAD merged into it once, the differences between that last merge and current HEAD need to be gathered and applied to the branch. This is done by finding out when the last time HEAD was merged with the branch. Hopefully you tagged your branch. Repeat steps 1 and 2 from the previous section to create a tag for HEAD and to create a tag for your branch so you can have a backup/reference point. Then, perform the following if you have tagged the branch when merging the last time:
$ cvs update -kk -j -j |
Run the command from within the branched version. is the old tag in HEAD from the last time you merged (the tag that you created in Step one from the previous section). If you in this case, the format will likely be the following:
$ cvs update -kk -j UPDATE_HEAD_36_BUG__06_16_2008 -j UPDATE_HEAD_36_BUG__07_23_2008 |
The first tag is the one created the last time HEAD was merged into the branch. The second tag is one that should have been just created. This will take all the differences between the two tags, and bring them into the branch. The next time a merge from HEAD into the branch occurs, this latest tag will be the "old" tag, and the new tag will be created at the time of the merge.
The reason for tagging the branch before a join/merge like this is to create a reference point to revert to if the need ever arises. The -kk option removes rcsid tags so that the cvs tag at the top doesn't get flagged as a conflict on every merge/join.
Merge HEAD into Current Branch Multiple Times (without tags)
If no tags have been created for the branch when HEAD was merged into a branch at a previous time, an alternative is to use the daily build tag. Find the commit message of the last time HEAD was merged into the branch and was committed and select the daily build tag the day BEFORE that one (but only if the commit was before the daily build that day, i.e. before lunch time for GMT -06:00). An example is provided below on how to merge without tagging:
$ cvs update -kk -j Tag_Branch -j HEAD> |
Run the command from within the branched version.
----------------------------------
To Avoide network confusion :-
use :- alias cvs=`cvs -z9`
causes cvs to use compression level 6.
Good links for it:-
- http://datagrams.blogspot.com/2009/01/how-to-deploy-cvs-concurrent-versions.html
- http://kb.wisc.edu/middleware/page.php?id=4087
- http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_10.html#SEC85
- http://ximbiot.com/cvs/wiki/Special/Index
Thanks,
-Amaresh
No comments:
Post a Comment