Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-29T20:10:04Z

Rgowda: /* Conclusion */

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* Methods
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.It mentions the usage of Reflections and the advantages and disadvantages of using Reflection. A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-29T19:57:48Z

Rgowda: /* Additional Reading */

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* Methods
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-29T19:56:45Z

Rgowda:

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* Methods
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-29T19:45:07Z

Rgowda:

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* Methods
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-29T19:38:31Z

Rgowda:

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* Methods
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
Send method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

respond_to method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-29T19:06:44Z

Rgowda:

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common computer programming concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* Super classes of any class
* Methods
* class fields
* Interfaces

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements dynamic binding of objects. Dynamic binding plays a very important role in metaprogramming.

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
Symbols are objects used to represent names and strings inside a Ruby interpreter. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
Send method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

respond_to method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named 'method_missing'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a NoMethodError.

Overriding 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-21T01:53:53Z

Rgowda:

==Introduction==
Reflection is a relatively common computer programming concept where in the program has the inherant ability to examine itself at runtime. Based on its observations the program can modify it's behaviour for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* Super classes of any class
* Methods
* class fields
* Interfaces

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as introspection and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements dynamic binding of objects. Dynamic binding plays a very important role in metaprogramming.

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
Symbols are objects used to represent names and strings inside a Ruby interpreter. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
Send method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

respond_to method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named 'method_missing'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a NoMethodError.

Overriding 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-21T01:48:49Z

Rgowda:

==Introduction==
Reflection is a relatively common computer programming concept where in the program has the inherant ability to examine itself at runtime. Based on its observations the program can modify it's behaviour for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* Super classes of any class
* Methods
* class fields
* Interfaces

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as introspection and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements dynamic binding of objects. Dynamic binding plays a very important role in metaprogramming.

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
Symbols are objects used to represent names and strings inside a Ruby interpreter. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
Send method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

respond_to method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named 'method_missing'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a NoMethodError.

Overriding 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

===Example1===
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

===Example2===
Using method_missing to convert Roman numerals to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-21T01:47:12Z

Rgowda:

==Introduction==
Reflection is a relatively common computer programming concept where in the program has the inherant ability to examine itself at runtime. Based on its observations the program can modify it's behaviour for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* Super classes of any class
* Methods
* class fields
* Interfaces

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as introspection and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements dynamic binding of objects. Dynamic binding plays a very important role in metaprogramming.

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

==Symbols and their usage in reflection techniques==

===Basics===
Symbols are objects used to represent names and strings inside a Ruby interpreter. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
Send method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

respond_to method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named 'method_missing'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a NoMethodError.

Overriding 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

===Example1===
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

===Example2===
Using method_missing to convert Roman numerals to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]

File:Slicing.gif

2011-10-21T01:42:40Z

Rgowda:

File:Before binding.png

2011-10-21T01:42:08Z

Rgowda:

File:After binding.png

2011-10-21T01:41:35Z

Rgowda:

CSC/ECE 517 Fall 2011/ch4 4f rs

2011-10-21T01:11:22Z

Rgowda:

==Introduction==
Reflection is a relatively common computer programming concept where in the program has the inherant ability to examine itself at runtime. Based on its observations the program can modify it's behaviour for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith in 1992.

==Reflection==
Reflection is the ability of a program or a computation to examine and modify itself at run time even though it does not have enough information at compile time. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

5.class #=> Fixnum

"hello".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* Super classes of any class
* Methods
* class fields
* Interfaces

Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

== Types of reflection ==
There are two basic types of reflection. They are:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as introspection and intercession. These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection by example==
===C#===
<pre>
int val = 20;
System.Type type = val.GetType();
System.Console.WriteLine(type);
</pre>
Output is type of the variable "val" = System.Int32

===Smalltalk===
<pre>
w := Workspace new.
w openLabel:'My Workspace'
w inspect
</pre>
Here we can inspect all the methods available to the instance 'w'.

===Java===
<pre>
import java.lang.reflect.*;
public class Fclass{
public static void main(String[] args){
Class cls = java.lang.Integer.class;
String info;
info = cls.getName(); // It will show java.lang.Integer
System.out.println(info);
}
}
</pre>
cls.getName() gives the complete class name which is printed out as the output of the above code is "java.lang.Integer"

===PHP===
<pre>
$reflector = new ReflectionClass("SimpleXMLElement");
echo $reflector;
</pre>
Output of this example is the complete class map of the class SimpleXMLElement.

==Dynamic binding : Making reflection possible==

Ruby implements dynamic binding of objects. Dynamic binding plays a very important role in metaprogramming.

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

==Symbols and their usage in reflection techniques==

===Basics===
Symbols are objects used to represent names and strings inside a Ruby interpreter. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

===Usage in reflection techniques===
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

===Examples===

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
Send method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

respond_to method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>

==method_missing==

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named 'method_missing'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a NoMethodError.

Overriding 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

===Example1===
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

===Example2===
Using method_missing to convert Roman numerals to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end

</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Advantages and disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids , auto-completion and documentation easy in development tools for programmers.
* Debugging: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions.
* Test Harness : Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness : Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Reflection introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Since it provides access to the internals of a class or an encapsulated object security becomes a major issue.
* Since it is run-time binding we lose the security of compile time checks and verification.

==Additional Reading==

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:38:24Z

Rgowda: /* ClearCase Version Management System */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase: =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

== Sample Workflow involving Clearcase ==

This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view:
<pre>cleartool mkview -tag atag storage-location </pre>

Command to create a new file:
<pre>cleartool mkelem <file_name></pre>

Command to create a new branch:
<pre>cleartool mkbranch -nc <version_selector></pre>

Command to checkout a file for editing:
<pre>cleartool co -nc <file_name></pre>

Command to check in a file after editing:
<pre>cleartool ci -nc <file_name></pre>

Command to check the current working view:
<pre>ct pwv</pre>

Command to view/edit the current config spec for the view:
<pre>ct catcs /edcs</pre>

Command to merge and deliver the code changes:
<pre>cleartool merge -to target-path -insert contributor-version-selector <name_version></pre>

Command to delete a file:
<pre>cleartool rmelem <file_name></pre>

Command to delete a view:
<pre>cleartool rmview <view_name></pre>

== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is cumbersome.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

Hence Version Control systems have to be chosen based on the requirements of the project and its team.

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:34:29Z

Rgowda: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

== Sample Workflow involving Clearcase ==

This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view:
<pre>cleartool mkview -tag atag storage-location </pre>

Command to create a new file:
<pre>cleartool mkelem <file_name></pre>

Command to create a new branch:
<pre>cleartool mkbranch -nc <version_selector></pre>

Command to checkout a file for editing:
<pre>cleartool co -nc <file_name></pre>

Command to check in a file after editing:
<pre>cleartool ci -nc <file_name></pre>

Command to check the current working view:
<pre>ct pwv</pre>

Command to view/edit the current config spec for the view:
<pre>ct catcs /edcs</pre>

Command to merge and deliver the code changes:
<pre>cleartool merge -to target-path -insert contributor-version-selector <name_version></pre>

Command to delete a file:
<pre>cleartool rmelem <file_name></pre>

Command to delete a view:
<pre>cleartool rmview <view_name></pre>

== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is cumbersome.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

Hence Version Control systems have to be chosen based on the requirements of the project and its team.

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:33:06Z

Rgowda: /* Choice of Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====

This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view:
<pre>cleartool mkview -tag atag storage-location </pre>

Command to create a new file:
<pre>cleartool mkelem <file_name></pre>

Command to create a new branch:
<pre>cleartool mkbranch -nc <version_selector></pre>

Command to checkout a file for editing:
<pre>cleartool co -nc <file_name></pre>

Command to check in a file after editing:
<pre>cleartool ci -nc <file_name></pre>

Command to check the current working view:
<pre>ct pwv</pre>

Command to view/edit the current config spec for the view:
<pre>ct catcs /edcs</pre>

Command to merge and deliver the code changes:
<pre>cleartool merge -to target-path -insert contributor-version-selector <name_version></pre>

Command to delete a file:
<pre>cleartool rmelem <file_name></pre>

Command to delete a view:
<pre>cleartool rmview <view_name></pre>

== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is cumbersome.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

Hence Version Control systems have to be chosen based on the requirements of the project and its team.

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:31:09Z

Rgowda: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====

This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view:
<pre>cleartool mkview -tag atag storage-location </pre>

Command to create a new file:
<pre>cleartool mkelem <file_name></pre>

Command to create a new branch:
<pre>cleartool mkbranch -nc <version_selector></pre>

Command to checkout a file for editing:
<pre>cleartool co -nc <file_name></pre>

Command to check in a file after editing:
<pre>cleartool ci -nc <file_name></pre>

Command to check the current working view:
<pre>ct pwv</pre>

Command to view/edit the current config spec for the view:
<pre>ct catcs /edcs</pre>

Command to merge and deliver the code changes:
<pre>cleartool merge -to target-path -insert contributor-version-selector <name_version></pre>

Command to delete a file:
<pre>cleartool rmelem <file_name></pre>

Command to delete a view:
<pre>cleartool rmview <view_name></pre>

== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is annoying.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

Hence Version Control systems have to be chosen based on the requirements of the project and its team.

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:26:38Z

Rgowda: /* Choice of Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is annoying.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

Hence Version Control systems have to be chosen based on the requirements of the project and its team.

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:25:14Z

Rgowda:

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is annoying.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:14:25Z

Rgowda: /* Introduction */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:13:39Z

Rgowda: /* Introduction */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems.It extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:13:07Z

Rgowda: /* Choice of Version Control Systems */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems.It extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:06:39Z

Rgowda:

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Choice of Version Control Systems ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.
There are a number of solutions which are available for programmers.Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.
The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:49:35Z

Rgowda: /* Distributed Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:49:19Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control|DVCS]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:48:54Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control|CVS]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control|DVCS]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:48:36Z

Rgowda: /* Distributed Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control|[["CVS"]]]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control|DVCS]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:43:01Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control|[["CVS"]]]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:42:30Z

Rgowda: /* Summary of Centralized versus Distributed Approach */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:42:20Z

Rgowda: /* Distributed Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:41:34Z

Rgowda: /* See also */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:41:17Z

Rgowda: /* See also */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines if version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:33:51Z

Rgowda:

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:33:21Z

Rgowda: /* External links */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:32:22Z

Rgowda: /* External links */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/] Choosing a Version Control System
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:29:56Z

Rgowda: /* See also */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view: ct mkview -tag <view_name>
Sample command to create a new file: ct mkelem <file_name>

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: ct co -nc <file_name>
Sample command to check in a file: ct ci -nc <file_name> (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:08:40Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:08:26Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:07:58Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:07:44Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

File:RCS.png

2011-09-25T23:06:25Z

Rgowda: Local File Server

Local File Server

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:00:46Z

Rgowda:

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Distributed Version Control]]
==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T22:57:36Z

Rgowda: /* Distributed Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Distributed Version Control.|[''Centralized Version Control'']]]
==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control.|[''Distributed Version Control'']]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T22:57:20Z

Rgowda: /* Centralized Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Distributed Version Control.|[''Centralized Version Control'']]]
==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T22:56:24Z

Rgowda:

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control.|[''Distributed Version Control'']]]
==== Distributed Version Control ====
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by ddifferent teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]

File:CVS.png

2011-09-25T22:56:08Z

Rgowda: Centralized Version Control System

Centralized Version Control System

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T22:49:07Z

Rgowda: /* Distributed Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

[[Image:File-DVCS.png|thumb|200px|alt=Distributed Version Control.|[''Distributed Version Control'']]]
==== Distributed Version Control ====
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found here * [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [[here]]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]

File:File-DVCS.png

2011-09-25T22:48:02Z

Rgowda: uploaded a new version of "File:File-DVCS.png"

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T22:43:23Z

Rgowda: /* Local Version Control */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found here[ [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [[here]]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T22:31:43Z

Rgowda: /* Mercurial: */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only. It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]