Version Control:
Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to collaborate. Version Control is not just limited to source code as it can virtually handle all kinds of files (even binary files, although you cannot diff two binary files).
Revision control (also known as version control (system) (VCS), source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models, and other projects that may be worked on by a team of people. Changes to these documents are usually identified by incrementing an associated number or letter code, termed the "revision number", "revision level", or simply "revision" and associated historically with the person making the change. A simple form of revision control, for example, has the initial issue of a drawing assigned the revision number "1". When the first change is made, the revision number is incremented to "2" and so on.
Version control systems are most commonly stand-alone applications, but revision control is also embedded in various types of software like word processors (e.g. Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems. Integrated revision control is a key feature of wiki software packages such as MediaWiki, DokuWiki, TWiki, etc. In wikis, revision control allows for the ability to revert a page to a previous revision, which is critical for allowing editors to track each other's edits, correct mistakes, and defend public wikis against vandalism and spam.
Version Control makes life easier for programmer to work together on a project. They can edit the same file at the same time, as each programmer has its own copy of the file.
One of the most popular and commonly used tool for Version Control System is CVS (Concurrent Versioning System).
What is CVS:
CVS is a version control system. Using it, you can record the history of your source files.
For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS, you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.
You could of course save every version of every file you have ever created. This would however waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions.
CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each others' changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that two people never modify the same file at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.
Repository:
The CVS repository stores a complete copy of all the files and directories which are under version control.
Normally, you never access any of the files in the repository directly. Instead, you use CVS commands to get your own copy of the files into a working directory, and then work on that copy. When you've finished a set of changes, you check (or commit) them back into the repository. The repository then contains the changes which you have made, as well as recording exactly what you changed, when you changed it, and other such information. Note that the repository is not a subdirectory of the working directory, or vice versa; they should be in separate locations.
First we have to create a repository and then add files to it, then other user can checkout (get a local copy of the files). Once user has modified a file, he can commit back to repository. Once committed every other user can do an update to get the modified file. You can commit files, add files, remove files and vice versa. Usually a user decided to commit file after he has completed some task like added new functionality, fixed a bug or remove unused code etc.
Features:
CVS uses a client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server supports various flavors of Microsoft Windows and Linux), while CVS clients may run on any major operating-system platform.
Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other's toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.
If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification or convert the log data into a Web-based format.
Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow "anonymous read access", a feature pioneered by OpenBSD. This means that clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios.
Clients can also use the "update" command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.
CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.
CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) - in extreme cases the system may store individual copies of each version rather than deltas.
Software:
CVS comes as a built-in utility on nearly all unix and linux based OS. On windows one can use Tortoise CVS which does the same thing as well as it also provides a GUI based interface. Tortoise CVS can be downloaded from http://www.tortoisecvs.org/
Nowadays people are switching to SVN (Subversion) which is a successor of CVS. Some people tends to call SVN as a better CVS, as it overcomes some of the inherent problems and limitations of CVS. For you purpose it doesn't matter what you use for Version Control as the basics of both CVS and SVN are essentially the same. Once you have good grasped on any one of them, you can potentially use the other with no difficulties.
NB:
If you are programmer or in any way related to programming, there is no way forward before understanding the essentials of a Version Control System. A programmer should know about CVS.
As an exercise download and install tortoise CVS from http://www.tortoisecvs.org/ and try to checkout code from this open source repository.
After installing Tortoise CVS, type this from a command window or use GUI for this.
cvs -d
server:[email protected]:/ANONCVS checkout ants
External Resources:
http://en.wikipedia.org/wiki/Concurrent_Versions_System
http://en.wikipedia.org/wiki/Revision_control
http://ximbiot.com/cvs/manual/
http://www.network-theory.co.uk/docs/cvsmanual/index.html
This article heavily uses material from www.wikipedia.org
Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to collaborate. Version Control is not just limited to source code as it can virtually handle all kinds of files (even binary files, although you cannot diff two binary files).
Revision control (also known as version control (system) (VCS), source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models, and other projects that may be worked on by a team of people. Changes to these documents are usually identified by incrementing an associated number or letter code, termed the "revision number", "revision level", or simply "revision" and associated historically with the person making the change. A simple form of revision control, for example, has the initial issue of a drawing assigned the revision number "1". When the first change is made, the revision number is incremented to "2" and so on.
Version control systems are most commonly stand-alone applications, but revision control is also embedded in various types of software like word processors (e.g. Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems. Integrated revision control is a key feature of wiki software packages such as MediaWiki, DokuWiki, TWiki, etc. In wikis, revision control allows for the ability to revert a page to a previous revision, which is critical for allowing editors to track each other's edits, correct mistakes, and defend public wikis against vandalism and spam.
Version Control makes life easier for programmer to work together on a project. They can edit the same file at the same time, as each programmer has its own copy of the file.
One of the most popular and commonly used tool for Version Control System is CVS (Concurrent Versioning System).
What is CVS:
CVS is a version control system. Using it, you can record the history of your source files.
For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS, you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.
You could of course save every version of every file you have ever created. This would however waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions.
CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each others' changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that two people never modify the same file at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.
Repository:
The CVS repository stores a complete copy of all the files and directories which are under version control.
Normally, you never access any of the files in the repository directly. Instead, you use CVS commands to get your own copy of the files into a working directory, and then work on that copy. When you've finished a set of changes, you check (or commit) them back into the repository. The repository then contains the changes which you have made, as well as recording exactly what you changed, when you changed it, and other such information. Note that the repository is not a subdirectory of the working directory, or vice versa; they should be in separate locations.
First we have to create a repository and then add files to it, then other user can checkout (get a local copy of the files). Once user has modified a file, he can commit back to repository. Once committed every other user can do an update to get the modified file. You can commit files, add files, remove files and vice versa. Usually a user decided to commit file after he has completed some task like added new functionality, fixed a bug or remove unused code etc.
Features:
CVS uses a client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server supports various flavors of Microsoft Windows and Linux), while CVS clients may run on any major operating-system platform.
Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other's toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.
If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification or convert the log data into a Web-based format.
Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow "anonymous read access", a feature pioneered by OpenBSD. This means that clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios.
Clients can also use the "update" command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.
CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.
CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) - in extreme cases the system may store individual copies of each version rather than deltas.
Software:
CVS comes as a built-in utility on nearly all unix and linux based OS. On windows one can use Tortoise CVS which does the same thing as well as it also provides a GUI based interface. Tortoise CVS can be downloaded from http://www.tortoisecvs.org/
Nowadays people are switching to SVN (Subversion) which is a successor of CVS. Some people tends to call SVN as a better CVS, as it overcomes some of the inherent problems and limitations of CVS. For you purpose it doesn't matter what you use for Version Control as the basics of both CVS and SVN are essentially the same. Once you have good grasped on any one of them, you can potentially use the other with no difficulties.
NB:
If you are programmer or in any way related to programming, there is no way forward before understanding the essentials of a Version Control System. A programmer should know about CVS.
As an exercise download and install tortoise CVS from http://www.tortoisecvs.org/ and try to checkout code from this open source repository.
After installing Tortoise CVS, type this from a command window or use GUI for this.
cvs -d
server:[email protected]:/ANONCVS checkout antsExternal Resources:
http://en.wikipedia.org/wiki/Concurrent_Versions_System
http://en.wikipedia.org/wiki/Revision_control
http://ximbiot.com/cvs/manual/
http://www.network-theory.co.uk/docs/cvsmanual/index.html
This article heavily uses material from www.wikipedia.org
