How CVS will help to Realtime Developers ?

how-cvs-will-help-to-realtime-developers

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.

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

  1. Perform a diff between complete branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2
  1. Perform a diff between a single file in two branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 filename
  1. Perform a diff between different versions of a file:
$ cvs -q diff -u -r version1 -r version2 filename
  1. Perform a diff between working version and most up to date file in database:
$ cvs -q diff -u filename
  1. 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
  • More Help!!

Refer for more on This:-

          Click Me!!

Thanks,

-Amaresh Das

Tagged : / / / / / / / / / / / /

What are the Best Practices of CVS?

cvs-best-practices

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

Tagged : / / / / / / / / / / / / / / /

Introduction to CVS | Know ABout CVS | Quick Start Guide

cvs-introduction

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.
Tagged : / / / / / / / / / / / / /

CVS Best Practices – List of CVS Best Practices – CVS Tips

cvs-best-practices

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

Tagged : / / / / / / / / / / / / / /

Share common projects with two different projects in CVS

projects-in-cvs

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 

Tagged : / / / / / / / / / / / / / / / / /