CSC/ECE 517 Fall 2010/ch1 1a vc: Difference between revisions
Pseudonym1 (talk | contribs) No edit summary |
Pseudonym1 (talk | contribs) No edit summary |
||
| Line 5: | Line 5: | ||
Version control systems typically let us create versions of the resources, where each developer can work on a different version, therefore providing the flexibility. There are a whole bunch of features provided by the new Versioning Systems. We shall look at the evolution and history of the same in the subsequent sections. | Version control systems typically let us create versions of the resources, where each developer can work on a different version, therefore providing the flexibility. There are a whole bunch of features provided by the new Versioning Systems. We shall look at the evolution and history of the same in the subsequent sections. | ||
==Taxonomy of Version Control== | |||
Branch: When the development team needs to work on two distinct copies of a project, a branch is created. [2] The branch is a replica of the existing code at the time of its creation. On creation of the branch, changes made to a branch are confined to it and are not visible in any other branch. | |||
Repository: Repository is the data store where all the versions of all the files in the project are stored. A repository may be centralized or distributed. | |||
Check-Out: Creating a working copy of the files in the repository on a local machine is called Check-out. Every user who checks out a file has a working copy of the file on his computer. Changes made to the working copy are not visible to the team members | |||
Check-In: Putting back the edited files to the repository for use by everybody is called Check-In | |||
Merge: Merging is the process of combining different working copies of the file into the repository.[3] Each developer is allowed to work on their independent working copies, and everyone’s changes to a single file are combined by merging | |||
Label: A label is an identifier given to a branch when created. Also known as Tag | |||
Trunk: The highest location of the repository is called Trunk. | |||
| Line 12: | Line 28: | ||
*[http://en.wikipedia.org/wiki/Concurrent_Versions_System Concurrent Version Systems(CVS)] | *[http://en.wikipedia.org/wiki/Concurrent_Versions_System Concurrent Version Systems(CVS)] | ||
*[http://www.ibm.com/developerworks/java/library/j-subversion/index.html#N1007B] | *[http://www.ibm.com/developerworks/java/library/j-subversion/index.html#N1007B] | ||
*[http://www.ericsink.com/scm/scm_branches.html] | |||
*[ http://www.tigris.org/nonav/scdocs/ddCVS_cvsglossary.html] | |||
Revision as of 22:56, 5 September 2010
Introduction
Versioning Systems are typically used in a software facility(s), and employed for the primary purposes of collaborative work. While working on a project with common resources (files, folders, information etc.), it becomes essential to put a definite order on the sanctity of the data if the resources are editable.
For example, if there are 10 people working on an assignment, and 3 people are working on the same file. It becomes important on how they can add/modify data such that all are neither locked out waiting for a lock put by anyone, nor there is any inconsistency in the data.
Version control systems typically let us create versions of the resources, where each developer can work on a different version, therefore providing the flexibility. There are a whole bunch of features provided by the new Versioning Systems. We shall look at the evolution and history of the same in the subsequent sections.
Taxonomy of Version Control
Branch: When the development team needs to work on two distinct copies of a project, a branch is created. [2] The branch is a replica of the existing code at the time of its creation. On creation of the branch, changes made to a branch are confined to it and are not visible in any other branch.
Repository: Repository is the data store where all the versions of all the files in the project are stored. A repository may be centralized or distributed.
Check-Out: Creating a working copy of the files in the repository on a local machine is called Check-out. Every user who checks out a file has a working copy of the file on his computer. Changes made to the working copy are not visible to the team members
Check-In: Putting back the edited files to the repository for use by everybody is called Check-In
Merge: Merging is the process of combining different working copies of the file into the repository.[3] Each developer is allowed to work on their independent working copies, and everyone’s changes to a single file are combined by merging
Label: A label is an identifier given to a branch when created. Also known as Tag
Trunk: The highest location of the repository is called Trunk.