Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T22:08:40Z

Pvthakka: /* References */

==Design Pattern==
A [http://en.wikipedia.org/wiki/Software_design_pattern software design pattern] is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a [http://en.wikipedia.org/wiki/Template template] that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_(computer_science)&ei=e8x9UP76EYfO9QSaqIHgAw&usg=AFQjCNEi_fFQxGdN5EgaYjs39AP1_WV9Vg objects], services, processes, [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDgQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThread_(computing)&ei=jMx9UJDfFofA9gSCvYDIBA&usg=AFQjCNHVNxWptDxJ9hDcMD_N5JtVFZX9Ow threads], components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&sqi=2&ved=0CCoQFjAB&url=http%3A%2F%2Fwww.oodesign.com%2Fadapter-pattern.html&ei=u8x9UMmUI4aK8QSE7YHoDg&usg=AFQjCNHBiT1X1w8RNvDaj_11MvharrKziA Adapter pattern] provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FStrategy_pattern&ei=zcx9UMKnFIXA9gTVmIHwCQ&usg=AFQjCNGl3o_1x2n2_FUSSLX9qu5qjlOGmA Algorithm strategy patterns], [http://www.computationaldesign.ca/projects Computational design patterns], [http://pic.dhe.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.ilog.jrules.doc%2FContent%2FBusiness_Rules%2FDocumentation%2F_pubskel%2FJRules%2Fps_JRules_Global933.html Execution patterns], [http://java-x.blogspot.com/2006/12/implementing-strategy-pattern-in-java.html Implementation strategy patterns], [http://gsraj.tripod.com/design/structural.html Structural design patterns].

==Proxy pattern==
The [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern], also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A [http://msdn.microsoft.com/en-us/library/windows/desktop/dd373867%28v=vs.85%29.aspx proxy object] has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A [http://c2.com/cgi/wiki?RemoteProxy remote proxy] provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A [http://www.javabeat.net/2007/09/working-with-virtual-proxy-pattern/ virtual proxy] allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A [http://users.soe.ucsc.edu/~pohl/Winter01/Design2/sld047.htm copy-on-write] defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A [http://www.cymphonix.com/AnonymousProxy.html protection proxy] provides different clients with different levels of access to a target object.

===Cache Proxy===
A [http://www.blackwasp.co.uk/Proxy.aspx cache proxy] provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A [http://www.cs.sjsu.edu/~pearce/oom/patterns/behavioral/proxy.htm firewall proxy] protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A [http://rezagh.wikidot.com/sync-proxy-pattern synchronization proxy] provides multiple accesses to a target object.

===Smart reference Proxy===
A [http://www.theserverside.com/discussions/thread.tss?thread_id=10880 smart reference proxy] provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An [http://www.oodesign.com/adapter-pattern.html adapter pattern] translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A [http://www.oodesign.com/bridge-pattern.html Bridge Pattern] decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A [http://www.dofactory.com/Patterns/PatternComposite.aspx composite pattern] is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The [http://www.oodesign.com/decorator-pattern.html decorator pattern] can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A [http://www.dofactory.com/Patterns/PatternFacade.aspx facade] is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A [http://www.oodesign.com/flyweight-pattern.html flyweight] is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
[http://www.corej2eepatterns.com/Patterns2ndEd/FrontController.htm Front controllers] are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A [http://briancray.com/posts/javascript-module-pattern module pattern] is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
===Comparison of Proxy pattern and Facade Pattern===
*The proxy pattern adds behavior whereas the façade pattern simplifies behavior.
*Proxies are optional, facades are not.

===Comparison of Adapter Pattern and Facade Pattern===
*In adapter pattern, the interface that is being adapted might already exist.
*The adapter pattern preserves polymorphism. A façade provides an idealized flexible interface which can be modified anytime as requirements come in.
*Adapters are usually small and hence do not have performance issues whereas facades are huge.

===Comparison of Proxy pattern and Adapter pattern===
*An adapter pattern changes the interface of the service whereas proxy pattern changes the behavior.
*An adapter pattern preserves the behavior of the service whereas the proxy pattern preserves the interface.
*In adapter pattern client can use the service entity only by using the adapter whereas in proxy pattern a client can use the proxy or the adapter in the same way.
*The Proxy can be cast to the interface of the Service. The Adapter can be cast to the interface the Client expects.

==References==
*http://en.wikipedia.org/wiki/Software_design_pattern
*http://en.wikibooks.org/wiki/Computer_Science_Design_Patterns/Proxy
*http://www.dofactory.com/Patterns/
*http://en.wikipedia.org/wiki/Proxy_pattern
*http://www.oodesign.com/
*http://www.netobjectivestest.com/PatternRepository/index.php?title=AdapterVersusProxyVersusFacadePatternComparison
*[http://www.csc.ncsu.edu/faculty/efg/517/f12/schedule Class notes]
*[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&tp=&arnumber=4383091&contentType=Conference+Publications&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A4383083%29 IEEE paper 1]
*[http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5982228&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5982228 IEEE Paper 2]
*[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.75.3386%26rep%3Drep1%26type%3Dpdf&ei=Vdp9UKinJpD09gTr8oCwDA&usg=AFQjCNERJnpeBDZjXH6PrZnR_8zRQPkIZQ IEEE Paper 3]

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T22:06:59Z

Pvthakka:

==Design Pattern==
A [http://en.wikipedia.org/wiki/Software_design_pattern software design pattern] is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a [http://en.wikipedia.org/wiki/Template template] that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_(computer_science)&ei=e8x9UP76EYfO9QSaqIHgAw&usg=AFQjCNEi_fFQxGdN5EgaYjs39AP1_WV9Vg objects], services, processes, [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDgQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThread_(computing)&ei=jMx9UJDfFofA9gSCvYDIBA&usg=AFQjCNHVNxWptDxJ9hDcMD_N5JtVFZX9Ow threads], components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&sqi=2&ved=0CCoQFjAB&url=http%3A%2F%2Fwww.oodesign.com%2Fadapter-pattern.html&ei=u8x9UMmUI4aK8QSE7YHoDg&usg=AFQjCNHBiT1X1w8RNvDaj_11MvharrKziA Adapter pattern] provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FStrategy_pattern&ei=zcx9UMKnFIXA9gTVmIHwCQ&usg=AFQjCNGl3o_1x2n2_FUSSLX9qu5qjlOGmA Algorithm strategy patterns], [http://www.computationaldesign.ca/projects Computational design patterns], [http://pic.dhe.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.ilog.jrules.doc%2FContent%2FBusiness_Rules%2FDocumentation%2F_pubskel%2FJRules%2Fps_JRules_Global933.html Execution patterns], [http://java-x.blogspot.com/2006/12/implementing-strategy-pattern-in-java.html Implementation strategy patterns], [http://gsraj.tripod.com/design/structural.html Structural design patterns].

==Proxy pattern==
The [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern], also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A [http://msdn.microsoft.com/en-us/library/windows/desktop/dd373867%28v=vs.85%29.aspx proxy object] has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A [http://c2.com/cgi/wiki?RemoteProxy remote proxy] provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A [http://www.javabeat.net/2007/09/working-with-virtual-proxy-pattern/ virtual proxy] allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A [http://users.soe.ucsc.edu/~pohl/Winter01/Design2/sld047.htm copy-on-write] defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A [http://www.cymphonix.com/AnonymousProxy.html protection proxy] provides different clients with different levels of access to a target object.

===Cache Proxy===
A [http://www.blackwasp.co.uk/Proxy.aspx cache proxy] provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A [http://www.cs.sjsu.edu/~pearce/oom/patterns/behavioral/proxy.htm firewall proxy] protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A [http://rezagh.wikidot.com/sync-proxy-pattern synchronization proxy] provides multiple accesses to a target object.

===Smart reference Proxy===
A [http://www.theserverside.com/discussions/thread.tss?thread_id=10880 smart reference proxy] provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An [http://www.oodesign.com/adapter-pattern.html adapter pattern] translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A [http://www.oodesign.com/bridge-pattern.html Bridge Pattern] decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A [http://www.dofactory.com/Patterns/PatternComposite.aspx composite pattern] is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The [http://www.oodesign.com/decorator-pattern.html decorator pattern] can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A [http://www.dofactory.com/Patterns/PatternFacade.aspx facade] is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A [http://www.oodesign.com/flyweight-pattern.html flyweight] is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
[http://www.corej2eepatterns.com/Patterns2ndEd/FrontController.htm Front controllers] are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A [http://briancray.com/posts/javascript-module-pattern module pattern] is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
===Comparison of Proxy pattern and Facade Pattern===
*The proxy pattern adds behavior whereas the façade pattern simplifies behavior.
*Proxies are optional, facades are not.

===Comparison of Adapter Pattern and Facade Pattern===
*In adapter pattern, the interface that is being adapted might already exist.
*The adapter pattern preserves polymorphism. A façade provides an idealized flexible interface which can be modified anytime as requirements come in.
*Adapters are usually small and hence do not have performance issues whereas facades are huge.

===Comparison of Proxy pattern and Adapter pattern===
*An adapter pattern changes the interface of the service whereas proxy pattern changes the behavior.
*An adapter pattern preserves the behavior of the service whereas the proxy pattern preserves the interface.
*In adapter pattern client can use the service entity only by using the adapter whereas in proxy pattern a client can use the proxy or the adapter in the same way.
*The Proxy can be cast to the interface of the Service. The Adapter can be cast to the interface the Client expects.

==References==
http://en.wikipedia.org/wiki/Software_design_pattern
http://en.wikibooks.org/wiki/Computer_Science_Design_Patterns/Proxy
http://www.dofactory.com/Patterns/
http://en.wikipedia.org/wiki/Proxy_pattern
http://www.oodesign.com/
http://www.netobjectivestest.com/PatternRepository/index.php?title=AdapterVersusProxyVersusFacadePatternComparison
http://www.csc.ncsu.edu/faculty/efg/517/f12/schedule
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&tp=&arnumber=4383091&contentType=Conference+Publications&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A4383083%29
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5982228&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5982228
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.75.3386%26rep%3Drep1%26type%3Dpdf&ei=Vdp9UKinJpD09gTr8oCwDA&usg=AFQjCNERJnpeBDZjXH6PrZnR_8zRQPkIZQ

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T22:03:22Z

Pvthakka: /* Comparisons */

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:42:35Z

Pvthakka: /* Similar patterns */

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:39:25Z

Pvthakka: /* Types of proxies */

==Design Pattern==
A [http://en.wikipedia.org/wiki/Software_design_pattern software design pattern] is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a [http://en.wikipedia.org/wiki/Template template] that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_(computer_science)&ei=e8x9UP76EYfO9QSaqIHgAw&usg=AFQjCNEi_fFQxGdN5EgaYjs39AP1_WV9Vg objects], services, processes, [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDgQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThread_(computing)&ei=jMx9UJDfFofA9gSCvYDIBA&usg=AFQjCNHVNxWptDxJ9hDcMD_N5JtVFZX9Ow threads], components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&sqi=2&ved=0CCoQFjAB&url=http%3A%2F%2Fwww.oodesign.com%2Fadapter-pattern.html&ei=u8x9UMmUI4aK8QSE7YHoDg&usg=AFQjCNHBiT1X1w8RNvDaj_11MvharrKziA Adapter pattern] provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FStrategy_pattern&ei=zcx9UMKnFIXA9gTVmIHwCQ&usg=AFQjCNGl3o_1x2n2_FUSSLX9qu5qjlOGmA Algorithm strategy patterns], [http://www.computationaldesign.ca/projects Computational design patterns], [http://pic.dhe.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.ilog.jrules.doc%2FContent%2FBusiness_Rules%2FDocumentation%2F_pubskel%2FJRules%2Fps_JRules_Global933.html Execution patterns], [http://java-x.blogspot.com/2006/12/implementing-strategy-pattern-in-java.html Implementation strategy patterns], [http://gsraj.tripod.com/design/structural.html Structural design patterns].

==Proxy pattern==
The [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern], also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A [http://msdn.microsoft.com/en-us/library/windows/desktop/dd373867%28v=vs.85%29.aspx proxy object] has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A [http://c2.com/cgi/wiki?RemoteProxy remote proxy] provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A [http://www.javabeat.net/2007/09/working-with-virtual-proxy-pattern/ virtual proxy] allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A [http://users.soe.ucsc.edu/~pohl/Winter01/Design2/sld047.htm copy-on-write] defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A [http://www.cymphonix.com/AnonymousProxy.html protection proxy] provides different clients with different levels of access to a target object.

===Cache Proxy===
A [http://www.blackwasp.co.uk/Proxy.aspx cache proxy] provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A [http://www.cs.sjsu.edu/~pearce/oom/patterns/behavioral/proxy.htm firewall proxy] protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A [http://rezagh.wikidot.com/sync-proxy-pattern synchronization proxy] provides multiple accesses to a target object.

===Smart reference Proxy===
A [http://www.theserverside.com/discussions/thread.tss?thread_id=10880 smart reference proxy] provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:32:46Z

Pvthakka: /* Proxy pattern */

==Design Pattern==
A [http://en.wikipedia.org/wiki/Software_design_pattern software design pattern] is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a [http://en.wikipedia.org/wiki/Template template] that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_(computer_science)&ei=e8x9UP76EYfO9QSaqIHgAw&usg=AFQjCNEi_fFQxGdN5EgaYjs39AP1_WV9Vg objects], services, processes, [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDgQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThread_(computing)&ei=jMx9UJDfFofA9gSCvYDIBA&usg=AFQjCNHVNxWptDxJ9hDcMD_N5JtVFZX9Ow threads], components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&sqi=2&ved=0CCoQFjAB&url=http%3A%2F%2Fwww.oodesign.com%2Fadapter-pattern.html&ei=u8x9UMmUI4aK8QSE7YHoDg&usg=AFQjCNHBiT1X1w8RNvDaj_11MvharrKziA Adapter pattern] provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FStrategy_pattern&ei=zcx9UMKnFIXA9gTVmIHwCQ&usg=AFQjCNGl3o_1x2n2_FUSSLX9qu5qjlOGmA Algorithm strategy patterns], [http://www.computationaldesign.ca/projects Computational design patterns], [http://pic.dhe.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.ilog.jrules.doc%2FContent%2FBusiness_Rules%2FDocumentation%2F_pubskel%2FJRules%2Fps_JRules_Global933.html Execution patterns], [http://java-x.blogspot.com/2006/12/implementing-strategy-pattern-in-java.html Implementation strategy patterns], [http://gsraj.tripod.com/design/structural.html Structural design patterns].

==Proxy pattern==
The [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern], also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A [http://msdn.microsoft.com/en-us/library/windows/desktop/dd373867%28v=vs.85%29.aspx proxy object] has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:11:22Z

Pvthakka:

==Design Pattern==
A [http://en.wikipedia.org/wiki/Software_design_pattern software design pattern] is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a [http://en.wikipedia.org/wiki/Template template] that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_(computer_science)&ei=e8x9UP76EYfO9QSaqIHgAw&usg=AFQjCNEi_fFQxGdN5EgaYjs39AP1_WV9Vg objects], services, processes, [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDgQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThread_(computing)&ei=jMx9UJDfFofA9gSCvYDIBA&usg=AFQjCNHVNxWptDxJ9hDcMD_N5JtVFZX9Ow threads], components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&sqi=2&ved=0CCoQFjAB&url=http%3A%2F%2Fwww.oodesign.com%2Fadapter-pattern.html&ei=u8x9UMmUI4aK8QSE7YHoDg&usg=AFQjCNHBiT1X1w8RNvDaj_11MvharrKziA Adapter pattern] provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FStrategy_pattern&ei=zcx9UMKnFIXA9gTVmIHwCQ&usg=AFQjCNGl3o_1x2n2_FUSSLX9qu5qjlOGmA Algorithm strategy patterns], [http://www.computationaldesign.ca/projects Computational design patterns], [http://pic.dhe.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.ilog.jrules.doc%2FContent%2FBusiness_Rules%2FDocumentation%2F_pubskel%2FJRules%2Fps_JRules_Global933.html Execution patterns], [http://java-x.blogspot.com/2006/12/implementing-strategy-pattern-in-java.html Implementation strategy patterns], [http://gsraj.tripod.com/design/structural.html Structural design patterns].

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:08:53Z

Pvthakka:

==Design Pattern==
A [http://en.wikipedia.org/wiki/Software_design_pattern software design pattern] is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a [http://en.wikipedia.org/wiki/Template template] that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FObject_(computer_science)&ei=e8x9UP76EYfO9QSaqIHgAw&usg=AFQjCNEi_fFQxGdN5EgaYjs39AP1_WV9Vg objects], services, processes, [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDgQFjAC&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThread_(computing)&ei=jMx9UJDfFofA9gSCvYDIBA&usg=AFQjCNHVNxWptDxJ9hDcMD_N5JtVFZX9Ow threads], components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&sqi=2&ved=0CCoQFjAB&url=http%3A%2F%2Fwww.oodesign.com%2Fadapter-pattern.html&ei=u8x9UMmUI4aK8QSE7YHoDg&usg=AFQjCNHBiT1X1w8RNvDaj_11MvharrKziA Adapter pattern] provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCcQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FStrategy_pattern&ei=zcx9UMKnFIXA9gTVmIHwCQ&usg=AFQjCNGl3o_1x2n2_FUSSLX9qu5qjlOGmA Algorithm strategy patterns], Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:05:00Z

Pvthakka: /* PHP */

==Design Pattern==
A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a template that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. Adapter pattern provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like Algorithm strategy patterns, Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
<?php
class ProxyBookList {
private $bookList = NULL;
//bookList is not instantiated at construct time
function __construct() {
}
function getBookCount() {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBookCount();
}
function addBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->addBook($book);
}
function getBook($bookNum) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->getBook($bookNum);
}
function removeBook($book) {
if (NULL == $this->bookList) {
$this->makeBookList();
}
return $this->bookList->removeBook($book);
}
//Create
function makeBookList() {
$this->bookList = new bookList();
}
}
class BookList {
private $books = array();
private $bookCount = 0;
public function __construct() {
}
public function getBookCount() {
return $this->bookCount;
}
private function setBookCount($newCount) {
$this->bookCount = $newCount;
}
public function getBook($bookNumberToGet) {
if ( (is_numeric($bookNumberToGet)) && ($bookNumberToGet <= $this->getBookCount())) {
return $this->books[$bookNumberToGet];
} else {
return NULL;
}
}
public function addBook(Book $book_in) {
$this->setBookCount($this->getBookCount() + 1);
$this->books[$this->getBookCount()] = $book_in;
return $this->getBookCount();
}
public function removeBook(Book $book_in) {
$counter = 0;
while (++$counter <= $this->getBookCount()) {
if ($book_in->getAuthorAndTitle() == $this->books[$counter]->getAuthorAndTitle()) {
for ($x = $counter; $x < $this->getBookCount(); $x++) {
$this->books[$x] = $this->books[$x + 1];
}
$this->setBookCount($this->getBookCount() - 1);
}
}
return $this->getBookCount();
}
}
class Book {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->author = $author_in;
$this->title = $title_in;
}
function getAuthor() {
return $this->author;
}
function getTitle() {
return $this->title;
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}
writeln( 'BEGIN TESTING PROXY PATTERN';
writeln('');
$proxyBookList = new ProxyBookList();
$inBook = new Book('PHP for Cats','Larry Truett');
$proxyBookList->addBook($inBook);
writeln('test 1 - show the book count after a book is added');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('test 2 - show the book');
$outBook = $proxyBookList->getBook(1);
writeln($outBook->getAuthorAndTitle());
writeln('');
$proxyBookList->removeBook($outBook);
writeln('test 3 - show the book count after a book is removed');
writeln($proxyBookList->getBookCount());
writeln('');
writeln('END TESTING PROXY PATTERN');
function writeln($line_in) {
echo $line_in." ";
}
?>

'''Explanation of Proxy Pattern'''
* ProxyBookList is created in place of the more resource intensive BookList. ProxyBookList will only instantiate BookList the first time a method in BookList is called.

'''Output'''
BEGIN TESTING PROXY PATTERN
test 1 - show the book count after a book is added
1
test 2 - show the book
PHP for Cats by Larry Truett
test 3 - show the book count after a book is removed
0
END TESTING PROXY PATTERN

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:00:36Z

Pvthakka: /* Exmaple 2 */

==Design Pattern==
A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a template that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. Adapter pattern provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like Algorithm strategy patterns, Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
*Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
http://sourcemaking.com/design_patterns/proxy/php

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T21:00:00Z

Pvthakka: /* C# */

==Design Pattern==
A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a template that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. Adapter pattern provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like Algorithm strategy patterns, Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
http://sourcemaking.com/design_patterns/proxy/php

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:59:46Z

Pvthakka: /* C# */

==Design Pattern==
A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a template that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. Adapter pattern provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like Algorithm strategy patterns, Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();

// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
http://sourcemaking.com/design_patterns/proxy/php

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:59:20Z

Pvthakka: /* C# */

==Design Pattern==
A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a template that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. Adapter pattern provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like Algorithm strategy patterns, Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
using System;
// MainApp test application
class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();

// Wait for user
Console.Read();
}
}
// "Subject"
abstract class Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
// "Proxy"
class Proxy : Subject
{
RealSubject realSubject;

public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}

realSubject.Request();
}
}

'''Explanation of Proxy Pattern'''
*A surrogate is provided for another object to control access to it.

'''Output'''
Called RealSubject.Request()

===PHP===
http://sourcemaking.com/design_patterns/proxy/php

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:56:19Z

Pvthakka: /* Java */

==Design Pattern==
A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar fashion in new contexts. A design pattern is a template that gives a solution to many similar situations. It cannot be directly transformed into code.
The solution is usually a simple mechanism because it is a collaboration between two or more classes, objects, services, processes, threads, components, or nodes that work together to solve the underlying architecture or development challenge
Design patterns documents simple mechanism that work. They provide a common vocabulary and taxonomy for developers and architects. They allow solutions to be described concisely as combinations of patterns. They enable reuse of architecture, design, and implementation decisions. All these features make design patterns very useful to software developers and architects.
Design patterns are typically represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. For instance consider the Adapter pattern. Adapter pattern provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are not compatible. To implement the Adapter pattern, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.
There are many design patterns like Algorithm strategy patterns, Computational design patterns, Execution patterns, Implementation strategy patterns, Structural design patterns.

==Proxy pattern==
The Proxy pattern, also known as a surrogate pattern, is a Structural design pattern. A proxy provides a surrogate or placeholder for another object to control access to it. There will be situations in which a client does not or cannot reference an object directly but still wants to interact with the object. A proxy object can act as an intermediary between the client and the target object. A proxy object has the same interface as the target object. The proxy holds a reference to the target object and can forward requests to the target as required. In effect, the proxy object has the authority to act on behalf of the client to interact with the target object.

==UML Class Diagram==

[[File:pt.jpg]]

By defining a Subject interface, the presence of the Proxy object standing in place of the RealSubject is transparent to the client.

==Applications of Proxy Pattern==
*A proxy can interface a network connection, a large object in memory, a file or any other resource that is expensive or impossible to duplicate.
*Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide.
*In situations where multiple copies of a complex object must exist, the proxy pattern can be used to reduce the application’s memory requirements. A single instance of the complex object and multiple proxy objects are created all of which are references to the original complex object. Any operation on the proxy is forwarded to the original object.

==Types of proxies==
===Remote Proxy===
A remote proxy provides a reference to an object located in a different address space on the same or different machine. They are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.

===Virtual Proxy===
A virtual proxy allows the creation of a memory intensive object on demand. The object will not be created until it is really needed.

===Copy-on-Write Proxy===
A copy-on-write defers cloning a target object until required by client actions. It is really a form of virtual proxy.

===Protection Proxy===
A protection proxy provides different clients with different levels of access to a target object.

===Cache Proxy===
A cache proxy provides temporary storage of the results of expensive target operations so that multiple clients can share the results.

===Firewall Proxy===
A firewall proxy protects targets from bad clients (or vice versa).

===Synchronization Proxy===
A synchronization proxy provides multiple accesses to a target object.

===Smart reference Proxy===
A smart reference proxy provides additional actions whenever a target object is referenced such as counting the number of references to the object.

==Examples of Proxy pattern==
===C++===
====Example 1====
class RealImage
{
int m_id;
public:
RealImage(int i)
{
m_id = i;
cout << " $$ ctor: " << m_id << '\n';
}
~RealImage()
{
cout << " dtor: " << m_id << '\n';
}
void draw()
{
cout << " drawing image " << m_id << '\n';
}
};
// 1. Design an "extra level of indirection" wrapper class
class Image
{
// 2. The wrapper class holds a pointer to the real class
RealImage *m_the_real_thing;
int m_id;
static int s_next;
public:
Image()
{
m_id = s_next++;
// 3. Initialized to null
m_the_real_thing = 0;
}
~Image()
{
delete m_the_real_thing;
}
void draw()
{
// 4. When a request comes in, the real object is
// created "on first use"
if (!m_the_real_thing)
m_the_real_thing = new RealImage(m_id);
// 5. The request is always delegated
m_the_real_thing->draw();
}
};
int Image::s_next = 1;
int main()
{
Image images[5];
for (int i; true;)
{
cout << "Exit[0], Image[1-5]: ";
cin >> i;
if (i == 0)
break;
images[i - 1].draw();
}
}

'''Explanation of Proxy Pattern'''
*The Wrapper class has an extra level on indirection
*The Wrapper class contains a pointer to the original class and it is initialized to NULL
*Lazy initialization is implemented.
*Request is always delegated.

'''Output'''
Exit[0], Image[1-5]: 2
$$ ctor: 2 drawing image 2
Exit[0], Image[1-5]: 4
$$ ctor: 4 drawing image 4
Exit[0], Image[1-5]: 2
drawing image 2
Exit[0], Image[1-5]: 0
dtor: 4
dtor: 2

====Exmaple 2====
class Subject
{
public:
virtual void execute() = 0;
};
class RealSubject: public Subject
{
string str;
public:
RealSubject(string s)
{
str = s;
}
/*virtual*/void execute()
{
cout << str << '\n';
}
};
class ProxySubject: public Subject
{
string first, second, third;
RealSubject *ptr;
public:
ProxySubject(string s)
{
int num = s.find_first_of(' ');
first = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
second = s.substr(0, num);
s = s.substr(num + 1);
num = s.find_first_of(' ');
third = s.substr(0, num);
s = s.substr(num + 1);
ptr = new RealSubject(s);
}
~ProxySubject()
{
delete ptr;
}
RealSubject *operator->()
{
cout << first << ' ' << second << ' ';
return ptr;
}
/*virtual*/void execute()
{
cout << first << ' ' << third << ' ';
ptr->execute();
}
};
int main()
{
ProxySubject obj(string("the quick brown fox jumped over the dog"));
obj->execute();
obj.execute();
}

'''Explanation of Proxy Pattern'''
Here ”->” and “.” operators give different results.

'''Output'''
the quick fox jumped over the dog
the brown fox jumped over the dog

===Java===
import java.io.*; import java.net.*;
// 5. To be compatible, an interface is created between the proxy and target
interface SocketInterface {
String readLine();
void writeLine( String str );
void dispose();
}
public class ProxyDemo {
public static void main( String[] args ) {
// 3. The client deals with the proxy
SocketInterface socket = new SocketProxy( "127.0.0.1", 8189,
args[0].equals("first") ? true : false );
String str = null;
boolean skip = true;
while (true) {
if (args[0].equals("second") && skip) {
skip = ! skip;
}
else {
str = socket.readLine();
System.out.println( "Receive - " + str ); // java ProxyDemo first
if (str.equals("quit")) break; // Receive - 123 456
} // Send ---- 234 567
System.out.print( "Send ---- " ); // Receive - 345 678
str = Read.aString(); //
socket.writeLine( str ); // java ProxyDemo second
if (str.equals("quit")) break; // Send ---- 123 456
} // Receive - 234 567
socket.dispose(); // Send ---- 345 678
}
}
class SocketProxy implements SocketInterface {
// 1. A proxy is created for the expensive or remote or sensitive object(target)
private Socket socket;
private BufferedReader in;
private PrintWriter out;
public SocketProxy( String host, int port, boolean wait ) {
try {
if (wait) {
// 2. A level of abstraction is created to encapsulate the complexity is the target
ServerSocket server = new ServerSocket( port );
socket = server.accept();
} else
socket = new Socket( host, port );
in = new BufferedReader( new InputStreamReader(
socket.getInputStream()));
out = new PrintWriter( socket.getOutputStream(), true );
} catch( IOException e ) {
e.printStackTrace();
}
}
public String readLine() {
String str = null;
try {
str = in.readLine();
} catch( IOException e ) {
e.printStackTrace();
}
return str;
}
public void writeLine( String str ) {
// 4. The proxy delegates the target
out.println( str );
}
public void dispose() {
try {
socket.close();
} catch( IOException e ) {
e.printStackTrace();
}
}
}

'''Explanation of Proxy Pattern'''
*A proxy is created for the expensive or remote or sensitive object(target)
*A level of abstraction is created to encapsulate the complexity is the target
*The client deals with the proxy
*The proxy delegates the target
*To be compatible, an interface is created between the proxy and target.

===C#===
http://sourcemaking.com/design_patterns/proxy/c%2523

===PHP===
http://sourcemaking.com/design_patterns/proxy/php

==Similar patterns==
===Adapter Pattern===
An adapter pattern translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface

===Bridge Pattern===
A Bridge Pattern decouples an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

===Composite Pattern===
A composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

===Decorator Pattern===
The decorator pattern can be used to extend (decorate) the functionality of a certain object dynamically, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class.

===Facade Pattern===
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software library easier to use, understand and test, since the facade has convenient methods for common tasks. It can make the library more readable, for the same reason. It can reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system. It wraps a poorly designed collection of API’s with a single well-designed API .

===Flyweight Pattern===
A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.

===Front Controller Pattern===
Front controllers are often used in web applications to implement workflows. While not strictly required, it is much easier to control navigation across a set of related pages (for instance, multiple pages might be used in an online purchase) from a front controller than it is to make the individual pages responsible for navigation.

===Module Pattern===
A module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language that does not support it, or only supports it, partially.

==Comparisons==
Comparison of

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:49:41Z

Pvthakka: /* Exmaple 2 */

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:49:09Z

Pvthakka: /* C++ */

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:37:56Z

Pvthakka: /* UML Class Diagram */

File:Pt.jpg

2012-10-16T20:37:16Z

Pvthakka:

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:34:56Z

Pvthakka:

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:33:26Z

Pvthakka:

File:Uml.PNG

2012-10-16T20:32:40Z

Pvthakka:

CSC/ECE 517 Fall 2012/ch2a 2w17 pt

2012-10-16T20:30:14Z

Pvthakka: Created page with "==Design Pattern== A software design pattern is a problem-solution pair that gives a general re-usable solution to a commonly occurring problem and can be applied in a similar f..."

CSC/ECE 517 Fall 2012

2012-10-16T20:24:12Z

Pvthakka:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:15:59Z

Pvthakka: /* Security */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.

====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
[http://en.wikipedia.org/wiki/Tag_%28metadata%29 Tagging] means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for [http://en.wikipedia.org/wiki/Agile_software_development agile development]. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.
*[http://en.wikipedia.org/wiki/Recursion Recursive] approach when pulling or merging one branch
*[http://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies Octopus] is used when merging two heads.

====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with [http://en.wikipedia.org/wiki/SHA-1 SHA 1] ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
====Limitations====
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:15:28Z

Pvthakka: /* Git */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.

====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
[http://en.wikipedia.org/wiki/Tag_%28metadata%29 Tagging] means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for [http://en.wikipedia.org/wiki/Agile_software_development agile development]. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.
*[http://en.wikipedia.org/wiki/Recursion Recursive] approach when pulling or merging one branch
*[http://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies Octopus] is used when merging two heads.

====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
====Limitations====
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:14:53Z

Pvthakka: /* Git */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.

====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
[http://en.wikipedia.org/wiki/Tag_%28metadata%29 Tagging] means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for [http://en.wikipedia.org/wiki/Agile_software_development agile development]. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.
*[http://en.wikipedia.org/wiki/Recursion Recursive] approach when pulling or merging one branch
*[http://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies Octopus] is used when merging two heads.

====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:13:58Z

Pvthakka: /* Merging */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.

====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
[http://en.wikipedia.org/wiki/Tag_%28metadata%29 Tagging] means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.
*[http://en.wikipedia.org/wiki/Recursion Recursive] approach when pulling or merging one branch
*[http://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies Octopus] is used when merging two heads.

====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:13:26Z

Pvthakka: /* Merging */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
[http://en.wikipedia.org/wiki/Tag_%28metadata%29 Tagging] means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional [http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge 3-way merge] algorithm.
*[http://en.wikipedia.org/wiki/Recursion Recursive] approach when pulling or merging one branch
*[http://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies Octopus] is used when merging two heads.

====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:09:48Z

Pvthakka: /* Tagged Commits */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
[http://en.wikipedia.org/wiki/Tag_%28metadata%29 Tagging] means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:09:03Z

Pvthakka: /* See also */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison on various VCS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:08:32Z

Pvthakka: /* Git */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:07:57Z

Pvthakka: /* Mercurial */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in [http://www.python.org/ Python]. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.

=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:07:05Z

Pvthakka: /* Limitations of CVS */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*[http://en.wikipedia.org/wiki/Symbolic_link Symbolic links] and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T16:05:49Z

Pvthakka: /* Examples of version control systems */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*[http://www.nongnu.org/cvs/ CVS]
*[http://www.bitkeeper.com/ Bitkeeper]
*[http://subversion.apache.org/ Subversion (SVN)]
*[http://www.monotone.ca/ Monotone]
*[http://www.perforce.com/ Perforce]
*[http://git-scm.com/ Git]
*[http://bazaar.canonical.com/en/ Bazaar]
*[http://www-01.ibm.com/software/awdtools/clearcase/ Clearcase]
*[http://mercurial.selenic.com/ Mercurial]

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T15:57:52Z

Pvthakka: /* Distributed Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

[[File:3_3.jpg]]

[http://en.wikipedia.org/wiki/Distributed_revision_control Distributed version control] uses [http://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer model] to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

File:3 2.jpg

2012-09-13T15:55:40Z

Pvthakka:

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T15:55:22Z

Pvthakka: /* Centralized Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
[[File:3_2.jpg]]

[http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Centralized Version Control] works on the basis of [http://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T15:51:33Z

Pvthakka: /* Local Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

[http://james-iry.blogspot.com/2010/11/local-version-control.html Local version control] is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore [http://en.wikipedia.org/wiki/Software_versioning versioning] is possible on files rather than projects. Examples of local version control systems are [http://www.gnu.org/software/rcs/ Revision Control System (RCS)] and [http://en.wikipedia.org/wiki/Source_Code_Control_System Source Code Control System (SCCS)].

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T15:47:31Z

Pvthakka: /* Local Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).

====Advantages of local version control====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

File:3 1.jpg

2012-09-13T15:45:44Z

Pvthakka:

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T15:44:53Z

Pvthakka: /* Local Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

[[File:3_1.jpg]]
Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).

====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:29:08Z

Pvthakka: /* SVN */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:28:04Z

Pvthakka: /* SVN */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
=='''SVN'''==
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:27:45Z

Pvthakka: /* Selecting a VCS */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
=='''CVS'''==
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

=='''Bazaar'''==
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

=='''Mercurial'''==
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
==='''SVN'''===
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

=='''Git'''==
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:25:27Z

Pvthakka:

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

==='''Local Version Control'''===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

==='''Centralized Version Control'''===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

==='''Distributed Version Control'''===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
==='''CVS'''===
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

==='''Bazaar'''===
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

==='''Mercurial'''===
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
==='''SVN'''===
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

==='''Git'''===
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:22:21Z

Pvthakka:

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

===Local Version Control===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

===Centralized Version Control===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

===Distributed Version Control===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
===CVS===
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

===Bazaar===
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

===Mercurial===
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
===SVN===
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

===Git===
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System 1. CVS]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29 2. Bazaar]
* [http://en.wikipedia.org/wiki/Mercurial 3. Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion 4. SVN]
* [http://en.wikipedia.org/wiki/Git_%28software%29 5. Git]

==See also==
* [http://www.tuxradar.com/content/which-version-control-system-best-you Which VCS is best for you]
* [http://en.wikipedia.org/wiki/Revision_control Wikipedia Revision Conrol]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/ Comparison of Git, Mercurial and CVS]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:17:23Z

Pvthakka: /* Local Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

===Local Version Control===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

===Centralized Version Control===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

===Distributed Version Control===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
===CVS===
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE:====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling:====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS:====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

===Bazaar===
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging:====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE:====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve:====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations:====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

===Mercurial===
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE:====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging:====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
===SVN===
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits:====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI’s:====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

===Git===
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging:====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security:====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags:====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI:====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29]
* [http://en.wikipedia.org/wiki/Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion]
* [http://en.wikipedia.org/wiki/Git_%28software%29]
* [http://www.tuxradar.com/content/which-version-control-system-best-you]
* [http://en.wikipedia.org/wiki/Revision_control]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/]

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:16:22Z

Pvthakka: /* Local Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

===Local Version Control===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[File:3_1.jpg|200px|thumb|right|]]
[[Image:3_1.jpg|thumb|225px|alt=Local Version Control.]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

===Centralized Version Control===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

===Distributed Version Control===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
===CVS===
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE:====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling:====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS:====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

===Bazaar===
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging:====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE:====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve:====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations:====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

===Mercurial===
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE:====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging:====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
===SVN===
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits:====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI’s:====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

===Git===
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging:====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security:====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags:====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI:====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29]
* [http://en.wikipedia.org/wiki/Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion]
* [http://en.wikipedia.org/wiki/Git_%28software%29]
* [http://www.tuxradar.com/content/which-version-control-system-best-you]
* [http://en.wikipedia.org/wiki/Revision_control]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/]

File:3 3.jpg

2012-09-13T08:13:36Z

Pvthakka:

CSC/ECE 517 Fall 2012/ch1 1w33 op

2012-09-13T08:12:28Z

Pvthakka: /* Distributed Version Control */

= Comparison of version control system from a programmer’s viewpoint =
==Introduction==
Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.
==Need of version control==
The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.
==Types of Version Control Systems==
There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

===Local Version Control===

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control include Revision Control System (RCS) and Source Code Control System (SCCS).
[[File:3_1.jpg|200px|thumb|right|]]
====Advantages of local version control:====
*Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

===Centralized Version Control===
Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.
====Advantages of centralized version control====
*In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
*Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

===Distributed Version Control===

Distributed version control uses peer to peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.
====Advantages of Distributed version control====
*Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
*This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer to peer network.
*It is easier to branch out from the baseline code and this helps in experimentation during development phase.
*It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
*As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

==Criteria for selecting a particular version control system==
*Size of project
*Number of developers working on the project
*Distribution of developers working on the project.
*Technology used for developing
*Plug-ins for IDE’s
*Learning curve
*Speed
*Functionality
*User interfaces (Web and GUI)

==Examples of version control systems==
*CVS
*Bitkeeper
*SVN
*Monotone
*Perforce
*Git
*Bazaar
*Subversion (SVN)
*Mercurial

==Selecting a VCS==
Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.
===CVS===
CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files.
Learning curve:
The learning curve for CVS is not too steep.
====GUI and IDE:====
CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.
====Conflict handling:====
A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

====Limitations of CVS:====
*Revisions created by commit are per file rather than containing multiple files.
*Symbolic links and not versioned leading to security risks.
*Unicode and non-ASCII filenames have limited support.
*Commits are not atomic leading to source corruption
*Text files are assumed to be the primary file type stored.
*No support for Distributed revision control.
*Branch operations are expensive since CVS was designed for working on a trunk.

===Bazaar===
Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS.
Distributed as well as Central:
Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there.
Work offline:
The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.
====Merging:====
Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.
====GUI and IDE:====
For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.
====Learning curve:====
Since it is one of the most feature heavy system, it is a slightly complicated.
====Limitations:====
It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

===Mercurial===
Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.
====Learning curve:====
Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.
====GUI and IDE:====
Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.
====Merging:====
Mercurial uses a 3-way merge.
====Limitations:====
*It does not allow merging of two parents.
*Extension based rather than being scriptable that may be ideal for some programmers
*Less out of box power.
===SVN===
SVN is a successor of CVS fixing most if its problems. Atomic operations are now included. Branch operations are easier and cheaper.

====Tagged Commits:====
Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.
====Merging/Conflict Resolution:====
A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.
====IDE and GUI’s:====
Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s.
Limitations:
*Does not use peer-to-peer model
*Contains bugs relating to renaming files and directories.
*Insufficient repository management commands.
*Slower that bazaar and Git.

===Git===
Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

====Merging:====
*The traditional 3-way merge algorithm.
*Recursive approach when pulling or merging one branch
*Octopus is used when merging two heads.
====Compatibility:====
Git works with SVN meaning you can use a subversion directory directly with Git.

====Security:====
The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

====Tags:====
Tags are extremely powerful. Any arbitrary description can be attached to the tag.

====IDE’s and GUI:====
Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.
Limitations:
*Learning curve is a little steep.
*Not optimal for single developers.
*Limited windows support as compared to linux.

==References==
<references/>
* [http://en.wikipedia.org/wiki/Concurrent_Versions_System]
* [http://en.wikipedia.org/wiki/Bazaar_%28software%29]
* [http://en.wikipedia.org/wiki/Mercurial]
* [http://en.wikipedia.org/wiki/Apache_Subversion]
* [http://en.wikipedia.org/wiki/Git_%28software%29]
* [http://www.tuxradar.com/content/which-version-control-system-best-you]
* [http://en.wikipedia.org/wiki/Revision_control]
* [http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/]