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.

Introduction to CVS

CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.
CVS is a production quality system in wide use around the world, including many free software projects.
While CVS stores individual file history in the same format as RCS, it offers the following significant advantages over RCS:

• It can run scripts which you can supply to log CVS operations or enforce site-specific polices.
• Client/server CVS enables developers scattered by geography or slow modems to function as a single team. The version history is stored on a single central server and the client machines have a copy of all the files that the developers are working on. Therefore, the network between the client and the server must be up to perform CVS operations (such as checkins or updates) but need not be up to edit or manipulate the current versions of the files. Clients can perform all the same operations which are available locally.
• In cases where several developers or teams want to each maintain their own version of the files, because of geography and/or policy, CVS’s vendor branches can import a version from another team (even if they don’t use CVS), and then CVS can merge the changes from the vendor branch with the latest files if that is what is desired.
• Unreserved checkouts, allowing more than one developer to work on the same files at the same time.
• CVS provides a flexible modules database that provides a symbolic mapping of names to components of a larger software distribution. It applies names to collections of directories and files. A single command can manipulate the entire collection.
• CVS servers run on most unix variants, and clients for Windows NT/95, OS/2 and VMS are also available. CVS will also operate in what is sometimes called server mode against local repositories on Windows 95/NT.

The post Introduction to CVS | Know ABout CVS | Quick Start Guide 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 CVS Best Practices – List of CVS Best Practices – CVS Tips appeared first on scmGalaxy.

Share common projects with two different projects in CVS If there are two or more projects in the repository, some of the files are common in these two projects and some are different.How to share the files that are same between these projects? How can archive this? How Changes in common files be reflected to both projects. Version of CVS 2.5.03  

Answer: The CVSROOT/modules2 file or the older CVSROOT/modules file can help with this sort of thing:

http://cvsnt.org/manual/html/Administrative-files.html#modulesOrhttp://cvsnt.org/manual/html/modules2.html  

Generally the best CM independent solution is to organise your project source code hierarchy within the CM tool in such a way that ‘common’code is in a project/module/directory of it’s own so it can be checked out and managed independently of other projects, ie:  

/repo/proja 

/repo/projb 

/repo/common 

Then you define a module where ‘projecta’ = ‘proja’+’common’ so when a person does ‘cvs co projecta’ they  get: 

/projecta/proja 

/projecta/common 

If your server is running on Linux then you can ‘cheat’ by simply symbolically linking the RCS file into two directories (though this may cause locking conflicts if the files are very busy).   

Thanks to:Arthur Barrett 

The post Share common projects with two different projects in CVS appeared first on scmGalaxy.