CSC/ECE 517 Fall 2010/ch1 1a vc

From Expertiza_Wiki
Revision as of 04:44, 6 September 2010 by Pseudonym1 (talk | contribs)
Jump to navigation Jump to search

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. [4] 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.


History

Source Code Control System (SCCS)

The exact time in history when and how the version systems came about into existence is unclear. However, we can estimate roughly that the version control system can be rooted to the Source Code Control System (SCCS) [3],[6]. It was developed by the Bell Labs in 1972. It is no longer prevalent, but the file format is still internally used today by other softwares like BitKeeper and Sablime[6]

Revision Control System(RCS)

The next generation of Version control system was the RCS. It was first released in 1982, and developed by Walter F. Tichy of Purdue University. It was considered to be a better version of SCCS. Also, the version syntax was very complicated. Usually the developers employed locking mechanism, and worked on a single branch(head).

One situation where RCS could prove to be useful is while a single user needs to work on a project. As RCS does not demand a central repository to be set up, and the administration and maintenance of files is easy, hence, it is easy.

The limitations of RCS were that RCS could only work on a single file. There was no way that multiple files in a project could be versioned.[7]


Concurrent Versions System(CVS)

CVS was one step ahead in the evolution of the Version control Systems. CVS is distributed under the public GNU license. One major advantage where the CVS edges over RCS is its Client-Server Architecture. RCS did not support a client-server architecture, which made it difficult for distributed development.

CVS based systems provided for the first, the ability to check out a version of the main copy in the repository. The developers could work on their individual copies, and later, push it back into their branches. Once all the development on the files was done, the developers could merge their code with the live copy. There is however a restriction posed by the CVS systems, that is it only allows modification of code on the latest version. This calls for the developers to regularly sync their code with main copy in the repository, so that the modifications done by other people are also covered.

CVS uses delta compression technique to save space on the multiple copies of the same files. In short, the CVS systems keep only one copy per se. Wherever another set of copy is needed, it just stores the differences from the original copy. If there is no difference between the two, then the 2 files are in sync, else out of sync. For more details, the Delta Compression could be accessed at http://en.wikipedia.org/wiki/Delta_compression

One of the biggest advantages of the CVS system was the ability for distributed development. However, there were quite a few areas where it lacked and called for better methods. To name a few, CVS could only work reliably with ASCII characters. It did not work well with other character sets for example UTF.Also, there was no atomicity of operations i.e. there was no way to ensure commit or rollback in case of an error. A detailed list of criticisms is mentioned at http://en.wikipedia.org/wiki/Concurrent_Versions_System#Criticism .

Subversioning(SVN)

Working on most of the criticisms of CVS mentioned before, in 2000, attempt to improve the structure of the CVS. The developers did not want to change the philosophy or change the structure of CVS in a totally new way, they just wanted to revamp whatever was done before. Partly because CVS was then the de facto standard for version control. [9]


References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch1_1a_vc&oldid=32744"