CSC/ECE 517 Spring 2015/ch1b 27 VC

Version Control Systems Integration

Version control systems are simply repositories of files which contain the source code of various computer programs. These systems provides monitored access to various users and enhances the distributive and collaborative development. Every change in the source code is logged along with the details of the collaborator and reasons for modification of the code. In Resource development which is generally carried out in teams, version controls plays the vital role in making the development easy. With version control every person in the team can work on the copy of the resources developed by other members of the team, make the necessary modifications and merge the changes with the modifications of other members.

Introduction

Version control is
 a
 fundamental
 part
 of
 software
 configuration
 management 
SCM. Also
 known
 as
 revision
 control, it 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 multiple
 users
 to
 edit
 the
 same
 document
 at
 the
 same
 time. This provides a
 valuable
 resource
 to team
 projects,

 thereby enabling a
 better
 working
 environment.
 Keeping
 records
 of
 all
 changes
 done to
 a
 set
 of
 information
 provides
 a
 reliable
 solution
 to
 data
 management,
 and
 an
 archive
 for
 future 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, he 
can
 checkout the
 corresponding file
 from
 the
 system, 
thus getting access to
 the 
most
 up‐to‐date
 version
 of
 it.
 Once
 the
 file
 has
 been
 amended,
 the
 user
 can
 then
 commit and
 re‐submit the
 file,
 updating
 the
 copy
 in
 the
 repository
, ready
 for
 use by other users.

The two widely used version control systems are the centralized version control and distributed version control. The main idea of the centralized version control is to have a central copy of the project typically on a server and the collaborators will make their changes to that central copy. In distributed version control system each programmer will be able to make a copy the project file and make necessary changes. While both the systems have their own advantages and disadvantages, they are chosen based on the requirements of the project. In some cases a hybrid of both the systems can also be employed.

 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

The basic purpose of a Version Control System was to maintain different versions of a file.

Following are some issues requiring a Version Control System:

• Change tracking : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
• Reversion : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
• Bug tracking : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
• Concurrency : The ability to have many people across separate geographic locations 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

Milestone of version control development.

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 where in only one person could check out and edit a file at one time.This led to serialized 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 worked
 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.In forward deltas the origin version is stored, all subsequent versions are stored as sets of changes or deltas where as in backword deltas, the most recent version is stored, all previous versions are stored as set ^|1| Logically similar to SCCS,it has a cleaner command interface and 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^|2|.

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. Distributed revision control took a peer-to-peer approach, as opposed to the client-server approach of centralized systems. The repository was split into several
s sub‐repositories
 for 
each
 section
 or 
module
 of 
a
 project.
The
 sub‐repositories 
could
 be
 stored 
on
 servers 
or
 local 
machines.This enabled every developer to edit his local sharable copy without having to connect to any network connection.Synchronization was conducted by exchanging patches (change-sets) from peer to peer.

Key Features of Version Control Systems

Tracking

As said earlier, tracking changes in the source code is one of the central ideas of the version control systems. Each and every change to the source code by the collaborators can be tracked so that if any change results in unpredicted/undesired output, the changes can be rolled back to the previous versions.

Committing

Instead of saving each and every change, version control systems allows individuals to submit the changes as a collection of actions. This collection of actions is known as committing in version control.

Branching and Merging

Branching allows the individuals to make a copy of the repository that can be modified in parallel without altering the remote repository. Branching also allows to commit changes to the local copy rather than directly committing changes to the master file. The changes made in the local repo can be merged with the changes of the remote repo which is called nothing but “Merging”.

VCS Integration in RubyMine

The various version control systems and the features supported by the RubyMine are Git, Subversion, CVS, Mercurial, Github.

Concurrent Version System

CVS is the oldest version control system and has a centralized architecture. It follows a client server architecture in which the projects are stored on the server. The two basic operations in this architecture are “check out” and “check in”. The client can check out the complete copy of a project file, make necessary changes and then check-in the file onto the server. Whenever a check-in is successful the version numbers of all the files in the project are incremented. Problem arises when multiple developers work on the same file remotely and try to check-in different versions. CVS overcomes this problem by accepting changes only to the latest version of the file. One problem with CVS is it doesn’t support rename tracking of the files. If renaming is done manually then the history might become invalid and we may not be able to recover the project state before rename.

Subversion

This is probably the most adopted version control system. It has a centralized client/server architecture. It was originally designed to be a better CVS. But its evolution far exceeded its primary goal of replacing CVS. Apart from having all the features of CVS, it contains many additional features such as versioning directories, atomic commits, merge tracking and file locking. SVN versions copying, deleting and renaming. The version numbers are per-commit and not per-file. No part of a commit takes effect until the entire has succeeded.

Mercurial

It is a distributed version control system like git. This is mainly designed for larger projects. Its key features are distributed architecture, it is fast, platform independent, extensible, easy to use and is open source. More information on Mercurial can be found here [hyperlink to 2].

Git

Git is free open source distributed version control system. With the Git integration enabled in RubyMine we can perform a range of basic Git operations. Git’s branching model is central feature which makes it stand apart from other version control systems. Git allows to have multiple local branches of the same file and the operations on the local files do not affect the remote repository unless and until the changes are pushed to the master. This offers more flexibility in trying out new ideas on the projects by providing the opportunity to switch back to the previous versions in case the idea doesn’t work the way it was designed to. Also all the branches need not be pushed to the remote repository. Only the branches in which changes are made can be pushed. Other VCSs also accomplish this tasks but it is incredibly easy in git. One feature that is unique in git is “Staging”. This is an intermediate stage wherein the commits can be formatted and reviewed before completing the commit. Each change can be committed separately in different commits.

“git add “ brings a file to staging.

“git commit” completes committing the changes.

This feature can also be disabled using git commit –a.

Github helped in establishing git as a great version control by providing an excellent front end for many projects. However, Git is not as easy and simple compared to CVS, SVN and Mercurial. But git has the advantage that it is suitable when all the developers are not connected to the master repo.

Using Git Integration Prerequisites

-Git is installed on your computer.

-It is strongly recommended that you use version 1.7.1.1 or higher. The location of the Git executable file is correctly specified on the Git page of the Settings dialog box.

-Git integration is enabled for the current project root or directory. If you are going to use a remote repository, create a Git hosting account first. You can access the remote repository through the username/password and keyboard interactive authentication methods supported by the Git integration or through a pair of ssh keys. Please note the following:

1) SSH keys are generated outside RubyMine. You can follow the instructions from Generating SSH keys or look for other guidelines.

2)Store the ssh keys in the home_directory \.ssh\ folder. The location of the home_directory is defined through environmental variables:

   -HOME for Unix-like operating systems.
   -userprofile for the Microsoft Windows operating system.

3)Make sure, the keys are stored in files with correct names:

   -id_rsa for the private key.
   -id_rsa.pub for the public key.

4) RubyMine supports a standard method of using multiple ssh keys, by means of creating .ssh/config file.

Git support

-When the Git integration with RubyMine is enabled, the Git item appears on the VCS menu, and on the context menus of the Editor and Project views.

-The files in the folders under the Git control are highlighted according to their status. See File Status Highlights for file status highlighting -conventions.

-Results of modifications show in the Changes tool window.

-When using the Git integration, it is helpful to open the Version Control tool window. Its Console tab displays the following data: All the commands generated based on the settings you specify through the RubyMine user interface. Information messages concerning the results of executing generated Git commands. Error messages.

Adding Files to a Local Git Repository

To add all currently unversioned files to Git control

Switch to the Changes tool window. Navigate to the Unversioned Files node and choose Add to VCS from the context menu or press Ctrl+Alt+A.

Adding specific files to a local Git repository.

Managing Branches

The Git Branches popup menu contains all the commands that are required to work with Git branches, and can be invoked in a number of ways.To open the Git Branches popup menu, do one of the following

-On the main VCS menu, choose Git | Branches .

-Open file in the editor, and on the context menu of the editor, choose Git | Branches .

-In the VCS operations popup menu, choose Branches .

-Click the Git widget in the Status bar:

Creating a New Branch

To create a new Git branch

1)Invoke the Branches menu as described in the section Accessing Git Branches Popup Menu.

2)On the pop-up menu, choose New Branch.

3)In the Create new branch dialog box, specify the branch name.Branch with the specified name is checked out, like

  git checkout -b 

To check out a new Git branch from a local branch

1)Invoke the Branches menu as described in the section Accessing Git Branches Popup Menu.

2)On the pop-up list that shows all available local and remote branches, click the desired one, and choose Checkout as new branch on the submenu.

3)In the Create new branch dialog box, specify the branch name.

To check out a new local branch from a remote branch

1)Invoke the Branches menu as described in the section Accessing Git Branches Popup Menu.

2)On the pop-up list that shows all available local and remote branches, click the desired one, and choose Checkout as new local branch .

3)In the Checkout new branch from <branch name> dialog box, specify the name of the new branch.Branch with the specified name is checked out, and put under tracking.

Managing branches.

Managing branches.

Setting Up a Local Git Repository

Although Git provides high flexibility in arranging data and your work with repositories, the following scenarios are most commonly used for setting up a local Git repository:

-Clone an existing remote repository and create a new project with the downloaded data. -Create a local repository which you can push to a remote location later, if necessary.

Cloning to a local Git repository.

Cloning to a local Git repository.

The various features supported by RubyMine can be found here. Here is a short introduction to the various version control systems in RubyMine.

References

https://www.jetbrains.com/ruby/features/ruby_version_control.html

http://git-scm.com

http://guides.beanstalkapp.com/version-control/intro-to-version-control.html

http://subversion.apache.org/

http://mercurial.selenic.com

https://www.atlassian.com/dvcs/overview/what-is-version-control

http://en.wikipedia.org/wiki/Concurrent_Versions_System