CVS Tips & Tricks

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.

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.

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.

1. Perform a diff between complete branches:

1. Perform a diff between a single file in two branches:

1. Perform a diff between different versions of a file:

1. Perform a diff between working version and most up to date file in database:

1. Perform a diff between working version and a specific database version:

Retrieving CVS Information on Files

To retrieve the current version and other relevant information about a file run:

To retrieve the entire change log pertaining to a file run:

Retrieving CVS Files Based Upon Revision

To retrieve a file from CVS based upon a revision number perform the following:

• 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:

• 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.

Revert to a tagged version of HEAD.

To create a branch in CVS perform the following:

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_.

Reverting to a Branch

To revert to a branch in CVS perform the following:

• 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

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.

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:

You will eventually have to commit your changes you should always do a tag on the branch after your commit.

Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option

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:

• 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:

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:

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
• More Help!!

Refer for more on This:-

          Click Me!!

Thanks,

-Amaresh Das

The post How CVS will help to Realtime Developers ? appeared first on scmGalaxy.

CVS Best Practices

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

The post What are the Best Practices of CVS? appeared first on scmGalaxy.