CSC/ECE 517 Fall 2010/ch1 1a vc: Difference between revisions
Pseudonym1 (talk | contribs) No edit summary |
Pseudonym1 (talk | contribs) No edit summary |
||
| Line 7: | Line 7: | ||
==Taxonomy of Version Control== | ==Taxonomy of Version Control== | ||
Branch: When the development team needs to work on two distinct copies of a project, a branch is created. <ref>[http://www.ericsink.com/scm/scm_branches.html]</ref> {return} 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. | Branch: When the development team needs to work on two distinct copies of a project, a branch is created. <ref>[http://www.ericsink.com/scm/scm_branches.html]</ref> {return} 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. | ||
| Line 15: | Line 15: | ||
Check-In: Putting back the edited files to the repository for use by everybody is called Check-In | 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 | 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 | ||
| Line 23: | Line 23: | ||
== | == References == | ||
*[1]: [http://en.wikipedia.org/wiki/Revision_control Revision Control Wikipedia] | |||
*[2]: [http://en.wikipedia.org/wiki/Concurrent_Versions_System Concurrent Version Systems(CVS)] | |||
*[3]: [http://www.ibm.com/developerworks/java/library/j-subversion/index.html#N1007B] | |||
*[4]: [http://www.ericsink.com/scm/scm_branches.html] | |||
*[5]: [http://www.tigris.org/nonav/scdocs/ddCVS_cvsglossary.html] | |||
Revision as of 23:38, 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. <ref>[1]</ref> {return} 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.
References
- [1]: Revision Control Wikipedia
- [2]: Concurrent Version Systems(CVS)
- [3]: [2]
- [4]: [3]
- [5]: [4]