CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av

Version control is a software utility used to manage the data, specially source code, within a software development environment. Managing the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing
 a
 detailed 
history
 of each document
.
 Version control
 implements
 several
 techniques
 to
 ensure
 the
 integrity of
 the
 information,
 while
 making
 use
 of
 minimal
 resources.
 This is a comprehensive list of version control software.

---

Introduction

Version control,
 also
 known
 as
 revision
 control,
 is
 a
 fundamental
 part
 of
 software
 configuration
 management
(SCM),
and
 acts
 as 
a 
key 
lifeline 
in 
a
 team 
environment.
Version
 control
 works 
by
 keeping
 a
 record
 of
 every
 unit
 of
 information
 and
 tracks
 the
 changes
 and
 updates
 made.


It also
 allows
 for
 multiple
 users
 to
 edit
 the
 same
 document
 at
 the
 same
 time,
 providing
 a
 valuable
 resource
 for
 team
 projects,
 and
 enabling
 a
 better
 working
 environment.
 Keeping
 records
 of
 all
 changes
 to
 a
 set
 of
 information
 provides
 a
 fail‐safe
 solution
 to
 data
 management,
 and
 an
 archive
 for
 subsequent
 reference.


Version control works
 by
 uniquely
 identifying
 each
 piece
 of
 information
 and
 recording
 the
 changes
 with
 it.
 The
 information
 is
 stored
 in
 a
 data repository,
 an
 information
 database,
 and
 can
 be
 accessed
 remotely
 or
 locally
 depending
 on
 the
 type
 of
 system.
 When
 a
 user
 is
 required
 to
 make
 changes
 to
 a
 document,
they 
can
 checkout the
 information
 from
 the
 system,
giving 
them
 the 
most
 up‐to‐date
 version
 of
 the
 file
 in
 their
 working
 copy .
 Once
 the
 file
 has
 been
 amended,
 the
 user
 can
 then
 commit ,
 re‐submit,
 the
 file
 updating
 the
 copy
 in
 the
 repository
 ready
 for
 use simple
 concept,
 there
 are
 many
 problems
 such
 as
 revision 
storage.

 While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and
 checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision
 from the system.

A typical history of a file version in SVN.

Trunk is the main copy of a project on which development progresses. Team members create branches (Similar to fork) from the Trunk and work on that copy.This provides the flexibility to modify the document in parallel along both branches . At the end changes are merged to the Trunk , and this process continues.

Issues Version Control addressed

Following were some of reasons version control was developed to address .

• Change tracking : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?
• Reversion : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).
• Bug tracking : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?
• Concurrency: the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
• History: the ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

---

History

Change and Configuration Control (CCC)

The history of Version control dates back to 1975 when Software Configuration Management(SCM) became commerical for the first time with the advent of CCC,which was developed by the SoftTool Corporation.CCC offered a central repository and provided a trunkery system that documented every change thus enhancing the accountability of the system and validity of the information stored.The changes were recorded as they occured,at regular intervals, during development and maintenance and at baseline release.

Source Code Control System(SCCS)

Then came the SCCS which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model to serialize development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

Diff Algorithm

The
 diff
 algorithm

 was developed
 by 
AT&T
 Bell
 Labs
 in
 1974,
 and
 prototyped
 by
 James 
W.
 Hunt
 in
 1976.
 
It works
 by
 finding
 the
 longest
 common
 subsequence,
 then
 comparing
 the
 data
 preceding and
 following it,
incorporating the changes in a diff or a patchfile.

Revsion Control System(RCS)

In the early 1980’s Walter Tichy introduced the RCS. RCS introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

Concurrent Version System(CVS)

Next came the CVS designed and originally implemented by Dick Grunein 1986 and then modified by Berliner et al in 1990. It became the defacto standard within the open soure community for many years because it didn't require files to be locked while checked out, reconciliating non-conflicting changes mechanically and requesting human intervention on conflicts.
One 
notable 
drawback
 to 
CVS
 was
 that 
it
 didn't support versioning of re-named or relocated material identifying them as new files instead of new versions.

Subversion(SVN)

Perceived shortcomings and faults in CVS eventually led to a new version control system called SVN around 2001.It was developed by CollabNet Inc. Unlike CVS, SVN committed changes atomically and significantly had better support for branches.

Distributed Version Control

The paradigm then shifted from client server architecture to a distributed system around 2001, with the development of systems like SVK, Bitkeeper, Mercurial, GNU Arch, DARCS, GIT, Bazaar, monotone, codeville, Vesta , Aegis and many more.In all these the repository is split into several
s sub‐repositories
 for 
each
 section
 or 
module
 of 
a
 project.
The
 sub‐repositories 
can
 be
 stored 
on
 servers 
or
 local 
machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found here

---

Big Shift in Paradigm

The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:

1. Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
2. Peer to Peer synchronization is not supported.
3. Offline commits is not supported.
4. Data back up is not adequate as there is a single repository.
5. Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-

1. Provides the users unlimited access to the repository even when they are not connected to the network.
2. Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
3. It has better merging and branching capabilities.
4. Information is more secure as each local repository acts as a backup of the central repository.
5. Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

---

Solution to these

How they solved these problem.

---

---

References

[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 The evolution of configuration management and version control

[2] Benjamin 
Neal,ECM 3406 
Dissertation 11th
 December
 2008

, Version
 Control:An
 Overview




---

External links

[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html

[2] http://catb.org/esr/writings/taoup/html/ch15s05.html

---