CSC/ECE 517 Fall 2010/ch1 1a br: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(44 intermediate revisions by 2 users not shown)
Line 9: Line 9:
= Introduction =
= Introduction =


Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are  released even today. Briefly, VCSs can be categorized into four [1]:
Version Control is the the administration and maintenance of a number of files used in a system as it is being developed or as it evolves. Other main purpose of VCS is to keep track of changes in the source code of programs. Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are  being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion  
#Tree versioning tools-central style: take two, example: Subversion  
#Tree versioning tool-distributed style, example Bazaar
#Tree versioning tool-distributed style, example: Bazaar, Git, Mercurial
 


= Source Code Control System =
= Source Code Control System =


The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]
The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It was designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]
 
 
Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.


Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS is an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.


= Revision Control System=
= Revision Control System=
Line 32: Line 29:
* Retrieve and apply 80 forward deltas on the branch
* Retrieve and apply 80 forward deltas on the branch


Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.


Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.


=Concurrent Version System=
=Concurrent Version System=


CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [9].
CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]
 
CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]


CVS offers the following significant advantages over RCS:
CVS offers the following significant advantages over RCS:
Line 46: Line 45:
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc


=Subversion=


=Subversion=
In early 2000 work began on Subversion by  Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]


Subversion is the next-in-line of  version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
Subversion is the next-in-line of  version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.  
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.  
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.  
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.  
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.


=Distributed Revision Control=


=Bazaar=
The first truly distributed version control system was the BitKeeper, which was developed by [http://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] in December 1999. Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include [16][17]:


Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].
* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.
 
Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -
 
* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.
 
One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.[18]
 
 
[[Image:CVCSvsDVCS.png |center| Distributed VCS versus Centralized CVS]]
 
 
[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar (Mar,2005), many other distributed version control software are available. They include: [http://en.wikipedia.org/wiki/Darcs Darcs] (Nov, 2004), [http://en.wikipedia.org/wiki/Monotone_(software) Monotone](Apr, 2003), [http://en.wikipedia.org/wiki/Mercurial Mercurial](Apr, 2005), [http://en.wikipedia.org/wiki/Git_(software) Git](Apr, 2005).  
 
Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].


= Summary =
= Summary =


Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]
Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]


= References =
= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.
[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.
[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.
[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.
[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.


[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation
[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.


[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS
[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.


[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System
[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.


[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind
[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.


[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems
[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003.  Retrieved September, 2010.


[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control
[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.


[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System
[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.


[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)
[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.


[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?
[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.


[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS
[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.


[http://www.linux.ie/articles/subversion/] Subversion - a better CVS
[http://en.wikipedia.org/wiki/Revision_control] Revision control, 2010. Retrieved September, 2010.


[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion
[http://en.wikipedia.org/wiki/Distributed_revision_control] Distributed revision control, 2010. Retrieved September, 2010.


[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion
[http://www.infoq.com/articles/dvcs-guide] Auvray S., Distributed Version Control Systems: A Not-So-Quick Guide Through, May 07, 2010

Latest revision as of 01:32, 18 September 2010

"A source code system is a giant UNDO key-a project-wide time machine" -Andy Hunt and Dave Thomas

Introduction

Version Control is the the administration and maintenance of a number of files used in a system as it is being developed or as it evolves. Other main purpose of VCS is to keep track of changes in the source code of programs. Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:

  1. File versioning tools, examples: SCCS, RCS
  2. Tree versioning tools-central style, example: CVS
  3. Tree versioning tools-central style: take two, example: Subversion
  4. Tree versioning tool-distributed style, example: Bazaar, Git, Mercurial

Source Code Control System

The very first version control system[5] is the Source Code Control System, which was originally written by Marc J. Rochkind in 1972 at Bell Labs, NJ. It was designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS is an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

Revision Control System

Revision Control System[7] is the successor to SCCS and written by Walter F. Tichy (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

  • Retrieve mainline revision 100
  • Retrieve and apply reverse deltas from 99 down to 10
  • Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.


Concurrent Version System

CVS was originally created by Dick Grune of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:

  • It can run scripts which log CVS operations or enforce site-specific polices.
  • CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
  • It can merge changes from non-CVS vendor branches.
  • Allows more than one developer to work on the same file at the same time
  • CVS servers run on most OS including unix-variants, Windows and OS/2 etc

Subversion

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of CollabNet, Inc. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:

  • In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
  • CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
  • In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
  • CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
  • If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

Distributed Revision Control

The first truly distributed version control system was the BitKeeper, which was developed by Linus Torvalds in December 1999. Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include [16][17]:

  • By default, only the working copy of the code base exist.
  • Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
  • Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

  • Peers are free to join as and when they wish without going through any elaborate approval process
  • Each working copy works like a branch
  • Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the Sun WorkShop TeamWare which was widely used in enterprise settings.[18]


Distributed VCS versus Centralized CVS
Distributed VCS versus Centralized CVS


Bazaar is one of the most famous open distributed style tree versioning tool. In addition to Bazaar (Mar,2005), many other distributed version control software are available. They include: Darcs (Nov, 2004), Monotone(Apr, 2003), Mercurial(Apr, 2005), Git(Apr, 2005).

Comparison of version control systems can be found here.

Summary

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]


References

[1] Introducing Bazaar. Retrieved September, 2010.

[2] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[3] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[4] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[5] Source Code Control Systems, 2010. Retrieved September, 2010.

[6] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[7] Revision control System, 2010. Retrieved September, 2010.

[8] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[9] Concurrent Versions System, 2010. Retrieved September, 2010.

[10] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[11] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[12] SVN vs CVS, 2005. Retrieved September, 2010.

[13] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[14] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[15] Apache Subversion, 2010. Retrieved September, 2010.

[16] Revision control, 2010. Retrieved September, 2010.

[17] Distributed revision control, 2010. Retrieved September, 2010.

[18] Auvray S., Distributed Version Control Systems: A Not-So-Quick Guide Through, May 07, 2010