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
