Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

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

cvs-best-practices

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

Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)
Subscribe
Notify of
guest
0 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x