Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-19T00:09:41Z

Vksingh: /* References */

'''How can [http://en.wikipedia.org/wiki/Agile_software_development Agile] complement other development methodologies'''

Similar to the [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] which give structure and name to commonly occuring problem, [http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] or system development methodology provides a framework which can be used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, [http://en.wikipedia.org/wiki/Software_design design], development, [http://en.wikipedia.org/wiki/Software_testing testing], documentation, [http://en.wikipedia.org/wiki/Computer_programming implementation] and evaluation.

The art of [http://en.wikipedia.org/wiki/Software_development_process Software Development] requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is then, the software developers role to communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodologies] involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems,time and resources required to implement the software.

3. Implementation
This is the phase where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A traceability matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of [http://en.wikipedia.org/wiki/Software_development_methodology Software development methodologies] have evolved over the years.Each have its own recognized strengths and weakness. Each system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of [http://en.wikipedia.org/wiki/Software_development_methodology Software development methodologies] are listed below.

#[http://en.wikipedia.org/wiki/Agile_software_development Agile software development].
#[http://en.wikipedia.org/wiki/Waterfall_model Waterfall model].
#[http://en.wikipedia.org/wiki/Spiral_model Spiral model].
#[http://en.wikipedia.org/wiki/Test-driven_development Test-driven development (TDD)].
#[http://en.wikipedia.org/wiki/Design-driven_development Design-driven development (D3)].

====General Problems faced during software development====

[http://en.wikipedia.org/wiki/Software_development_process Software development process] goes through the phases of requirements, design, development, testing and maintenance one after the other. It relies on the dream that once a step is 100% complete, it is also 100% right and it drives us to the delivery of a working software even the one the customer wants. But it doesn’t go that way in the software industry: customers don’t know what they need and use to ask many useless features, project leaders don’t succeed to write down the perfect requirements, analysts spend ages building up software architectures writing down pages of diagrams – software is definitely one of the most complex artifact humans can build up – and developers are human too, so they make mistakes too. It is often very hard to create exactly what the customer wants in software development. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_lyfCycle.png|650px|thumb|center| Software development cycle.]]

====Solution : [http://en.wikipedia.org/wiki/Agile_software_development Agile Methodology]====
“[http://en.wikipedia.org/wiki/Agile_software_development Agile]” methodologies are a new way of developing the modular object-oriented software used for enterprise SOA (Service Oriented Architecture ). [http://en.wikipedia.org/wiki/Agile_software_development Agile] programming breaks a project down into many mini-projects, instead of one huge "Big Bang".

The difference between [http://en.wikipedia.org/wiki/Agile_software_development Agile] development and rest of methodologies can be related to the difference between a modern missile and a medieval cannonball. With the right information and calculations, the target of a cannonball could be accurately plotted. But once fired, there was no way of altering its trajectory. If the calculations were wrong, or if the target moved, it would miss. By contrast the modern missile can follow a given target with a series of incremental changes to its direction. It can even be given alternative targets when in flight, if the original is no longer appropriate.

[[Image:agile_vs_waterfall.jpg|650px|thumb|center| agile_vs_waterfall.]]

[http://en.wikipedia.org/wiki/Agile_software_development Agile development] focuses on user adoption and experience. Wikipedia describes Agile software development as "a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. " [http://en.wikipedia.org/wiki/Agile_software_development Agile] encourages developers and end users to work closely with one another to ensure that unique user needs are met and that business activities are optimized. This is accomplished by developing in short development bursts (1 - 2 week periods) and gaining feedback on the usefulness of the software application. The feedback should come from the users that will actually be using the system. The thinking behind this approach is that users are subject matter experts and are more likely to adopt the change because they took an active role in designing and testing the new changes to the work flow through the iterative software development process.

Some of the well-known [http://en.wikipedia.org/wiki/Agile_software_development agile] [http://en.wikipedia.org/wiki/Software_development_process software development] methods:
#[http://en.wikipedia.org/wiki/Agile_Modeling Agile Modeling]
#[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process] (AUP)
#[http://en.wikipedia.org/wiki/Agile_Data_Method Agile Data Method]
#[http://en.wikipedia.org/wiki/Extreme_programming Extreme programming] (XP)
#[http://en.wikipedia.org/wiki/Scrum_(development) Scrum]

And some of the Agile practices

#[http://en.wikipedia.org/wiki/Test_Driven_Development Test Driven Development] (TDD)
#[http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavior Driven Development] (BDD)
#[http://en.wikipedia.org/wiki/Continuous_Integration Continuous Integration]
#[http://en.wikipedia.org/wiki/Pair_Programming Pair Programming]

----

===The [http://en.wikipedia.org/wiki/Agile_software_development Agile] Advantage===

An [http://en.wikipedia.org/wiki/Agile_software_development agile] methodology addresses risks earlier in the project, rather than later. It effectively manages user requirements and provides early value through executable software, instead of postponing the delivery of a working system until the final implementation. An [http://en.wikipedia.org/wiki/Agile_software_development agile] methodology flushes out and accommodates change early in the project life cycle and supplies an early architectural baseline. It also supports component-based systems development, facilitates team collaboration, and, most importantly, ensures quality. Following are some of the advantages of agile:

1. Address risks :
Its emphasis on architecture helps to deliver a fully functional working architecture early in the project, mitigating the technology risks.

2. Deliver early value:
An iterative approach enables a team to deliver functional solutions as soon as possible. Working prototypes demonstrate core functionality at the beginning of the project. An architectural baseline ensures that the technologies put into place will meet the fundamental requirements

3. Accommodate change early:
Project change isn’t bad; it’s the timing and magnitude of the change that causes problems. Agile methodologies manage and promote the discovery of necessary changes early in a project.

4. Facilitate team collaboration.

5. Ensure quality early.
----

===Conclusion===

[http://en.wikipedia.org/wiki/Agile_software_development Agile] has been successful in delivering quality product with lesser time.The most important gain of this methodology is that it almost removes the last minute surprises. Therefore the risk involved is very less. Below is the risk comparision between agile and [http://en.wikipedia.org/wiki/Waterfall_model waterfall model].

[[Image:agileVsWaterfallRisk.gif|650px|thumb|center| agile Vs Waterfall Risk.]]

----

===References===

[1] http://en.wikipedia.org/wiki/Agile_software_development

[2] http://en.wikipedia.org/wiki/List_of_software_development_philosophies

[3] http://en.wikipedia.org/wiki/Waterfall_model

[4] http://www.stsc.hill.af.mil/crosstalk/1995/01/comparis.asp

[5] http://eggsonbread.com/2009/07/10/agile-development-in-a-nutshell/

[6] [http://3.bp.blogspot.com/_s0xJIGrbtjQ/SWNwAADda9I/AAAAAAAAAA8/oqJyRlzMVmU/s1600-h/agile+vs+waterfall.JPG agile waterfall]

[7] http://sapnetweavermagazine.com/archive/Volume_04_%282008%29/Issue_01_%28Winter%29/v4i1a06.cfm?session=

----

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-19T00:05:59Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T23:55:32Z

Vksingh:

'''How can [http://en.wikipedia.org/wiki/Agile_software_development Agile] complement other development methodologies'''

Similar to the [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] which give structure and name to commonly occuring problem, [http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] or system development methodology provides a framework which can be used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, [http://en.wikipedia.org/wiki/Software_design design], development, [http://en.wikipedia.org/wiki/Software_testing testing], documentation, [http://en.wikipedia.org/wiki/Computer_programming implementation] and evaluation.

The art of [http://en.wikipedia.org/wiki/Software_development_process Software Development] requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is then, the software developers role to communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodologies] involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems,time and resources required to implement the software.

3. Implementation
This is the phase where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A traceability matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of [http://en.wikipedia.org/wiki/Software_development_methodology Software development methodologies] have evolved over the years.Each have its own recognized strengths and weakness. Each system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of [http://en.wikipedia.org/wiki/Software_development_methodology Software development methodologies] are listed below.

#[http://en.wikipedia.org/wiki/Agile_software_development Agile software development].
#Waterfall model.
#Spiral model.
#Test-driven development (TDD).
#Design-driven development (D3).

====General Problems faced during software development====

[http://en.wikipedia.org/wiki/Software_development_process Software development process] goes through the phases of requirements, design, development, testing and maintenance one after the other. It relies on the dream that once a step is 100% complete, it is also 100% right and it drives us to the delivery of a working software even the one the customer wants. But it doesn’t go that way in the software industry: customers don’t know what they need and use to ask many useless features, project leaders don’t succeed to write down the perfect requirements, analysts spend ages building up software architectures writing down pages of diagrams – software is definitely one of the most complex artifact humans can build up – and developers are human too, so they make mistakes too. It is often very hard to create exactly what the customer wants in software development. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_lyfCycle.png|650px|thumb|center| Software development cycle.]]

====Solution : [http://en.wikipedia.org/wiki/Agile_software_development Agile Methodology]====
“[http://en.wikipedia.org/wiki/Agile_software_development Agile]” methodologies are a new way of developing the modular object-oriented software used for enterprise SOA (Service Oriented Architecture ). [http://en.wikipedia.org/wiki/Agile_software_development Agile] programming breaks a project down into many mini-projects, instead of one huge "Big Bang".

The difference between [http://en.wikipedia.org/wiki/Agile_software_development Agile] development and rest of methodologies can be related to the difference between a modern missile and a medieval cannonball. With the right information and calculations, the target of a cannonball could be accurately plotted. But once fired, there was no way of altering its trajectory. If the calculations were wrong, or if the target moved, it would miss. By contrast the modern missile can follow a given target with a series of incremental changes to its direction. It can even be given alternative targets when in flight, if the original is no longer appropriate.

[[Image:agile_vs_waterfall.jpg|650px|thumb|center| agile_vs_waterfall.]]

[http://en.wikipedia.org/wiki/Agile_software_development Agile development] focuses on user adoption and experience. Wikipedia describes Agile software development as "a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. " [http://en.wikipedia.org/wiki/Agile_software_development Agile] encourages developers and end users to work closely with one another to ensure that unique user needs are met and that business activities are optimized. This is accomplished by developing in short development bursts (1 - 2 week periods) and gaining feedback on the usefulness of the software application. The feedback should come from the users that will actually be using the system. The thinking behind this approach is that users are subject matter experts and are more likely to adopt the change because they took an active role in designing and testing the new changes to the work flow through the iterative software development process.

Some of the well-known [http://en.wikipedia.org/wiki/Agile_software_development agile] [http://en.wikipedia.org/wiki/Software_development_process software development] methods:
#Agile Modeling
#Agile Unified Process (AUP)
#Agile Data Method
#Extreme programming (XP)
#Scrum

And some of the Agile practices

#Test Driven Development (TDD)
#Behavior Driven Development (BDD)
#Continuous Integration
#Pair Programming

----

===The [http://en.wikipedia.org/wiki/Agile_software_development Agile] Advantage===

An [http://en.wikipedia.org/wiki/Agile_software_development agile] methodology addresses risks earlier in the project, rather than later. It effectively manages user requirements and provides early value through executable software, instead of postponing the delivery of a working system until the final implementation. An [http://en.wikipedia.org/wiki/Agile_software_development agile] methodology flushes out and accommodates change early in the project life cycle and supplies an early architectural baseline. It also supports component-based systems development, facilitates team collaboration, and, most importantly, ensures quality. Following are some of the advantages of agile:

1. Address risks :
Its emphasis on architecture helps to deliver a fully functional working architecture early in the project, mitigating the technology risks.

2. Deliver early value:
An iterative approach enables a team to deliver functional solutions as soon as possible. Working prototypes demonstrate core functionality at the beginning of the project. An architectural baseline ensures that the technologies put into place will meet the fundamental requirements

3. Accommodate change early:
Project change isn’t bad; it’s the timing and magnitude of the change that causes problems. Agile methodologies manage and promote the discovery of necessary changes early in a project.

4. Facilitate team collaboration.

5. Ensure quality early.
----

===Conclusion===

[http://en.wikipedia.org/wiki/Agile_software_development Agile] has been successful in delivering quality product with lesser time.The most important gain of this methodology is that it almost removes the last minute surprises. Therefore the risk involved is very less. Below is the risk comparision between agile and waterfall model.

[[Image:agileVsWaterfallRisk.gif|650px|thumb|center| agile Vs Waterfall Risk.]]

----

===References===

[1]

----

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:55:51Z

Vksingh: /* Conclusion */

'''How can Agile complement other development methodologies'''

Similar to the design pattern which give structure and name to commonly occuring problem, Software development methodology or system development methodology provides a framework which can be used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

Software Development Methodology (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, design, developement, testing, documentation, implementation and evaluation.

The art of Software Development requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is the software devlopers role to then communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

Software Development Methodolgies involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems and the time and resources required to implement the software.

3. Implementation
This is the time where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A tracibility matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of Software Development Methodolgies have evolved over the years.Each have its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of them are listed below.

#Agile software development.
#Waterfall model.
#Spiral model.
#Test-driven development (TDD).
#Design-driven development (D3).

====General Problems faced during software development====

Software development process goes through the phases of Requirements, Design, Development, Testing & Maintenance one after the other. It relies on the dream that once a step is 100% complete, it is also 100% right and it drives us to the delivery of a working software even the one the customer wants. But it doesn’t go that way in the software industry: customers don’t know what they need and use to ask many useless features, project leaders don’t succeed to write down the perfect requirements, analysts spend ages building up software architectures writing down pages of diagrams – software is definitely one of the most complex artifact humans can build up – and developers are human too, so they make mistakes too. It is often very hard to create exactly what the customer wants in software development. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_lyfCycle.png|650px|thumb|center| Software development cycle.]]

====Solution : Agile Methodology====
“Agile” methodologies are a new way of developing the modular object-oriented software used for enterprise SOA. Agile programming breaks a project down into many mini-projects, instead of one huge “Big Bang.

The difference between Agile development and rest of methodologies can be related to the difference between a modern missile and a medieval cannonball. With the right information and calculations, the target of a cannonball could be accurately plotted. But once fired, there was no way of altering its trajectory. If the calculations were wrong, or if the target moved, it would miss. By contrast the modern missile can follow a given target with a series of incremental changes to its direction. It can even be given alternative targets when in flight, if the original is no longer appropriate.

[[Image:agile_vs_waterfall.jpg|650px|thumb|center| agile_vs_waterfall.]]

Agile development focuses on user adoption and experience. Wikipedia describes Agile software development as "a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. " Agile encourages developers and end users to work closely with one another to ensure that unique user needs are met and that business activities are optimized. This is accomplished by developing in short development bursts (1 - 2 week periods) and gaining feedback on the usefulness of the software application. The feedback should come from the users that will actually be using the system. The thinking behind this approach is that users are subject matter experts and are more likely to adopt the change because they took an active role in designing and testing the new changes to the workflow through the iterative software development process.

Some of the well-known agile software development methods:
#Agile Modeling
#Agile Unified Process (AUP)
#Agile Data Method
#Extreme programming (XP)
#Scrum

And some of the Agile practices

#Test Driven Development (TDD)
#Behavior Driven Development (BDD)
#Continuous Integration
#Pair Programming

----

===The Agile Advantage===

An agile methodology addresses risks earlier in the project, rather than later. It effectively manages user requirements and provides early value through executable software, instead of postponing the delivery of a working system until the final implementation. An agile methodology flushes out and accommodates change early in the project life cycle and supplies an early architectural baseline. It also supports component-based systems development, facilitates team collaboration, and, most importantly, ensures quality. Following are some of the advantages of agile:

1. Address risks :
Its emphasis on architecture helps to deliver a fully functional working architecture early in the project, mitigating the technology risks.

2. Deliver early value:
An iterative approach enables a team to deliver functional solutions as soon as possible. Working prototypes demonstrate core functionality at the beginning of the project. An architectural baseline ensures that the technologies put into place will meet the fundamental requirements

3. Accommodate change early:
Project change isn’t bad; it’s the timing and magnitude of the change that causes problems. Agile methodologies manage and promote the discovery of necessary changes early in a project.

4. Facilitate team collaboration.

5. Ensure quality early.

----

===Conclusion===

Agile has been successful in delivering quality product with lesser time.The most important gain of this methodology is that it almost removes the last minute surprises. Therefore the risk involved is very less. Below is the risk comparision between agile and waterfall model.

[[Image:agileVsWaterfallRisk.gif|650px|thumb|center| agile Vs Waterfall Risk.]]

----

===References===

[1]

----

File:AgileVsWaterfallRisk.gif

2009-11-18T05:54:42Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:49:42Z

Vksingh: /* '''Development methodologies''' */

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:32:21Z

Vksingh: /* Solution : Agile Methodology */

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:16:00Z

Vksingh: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:14:36Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:13:32Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T05:11:23Z

Vksingh: /* '''Development methodologies''' */

Similar to the design pattern which give structure and name to commonly occuring problem, Software development methodology or system development methodology is a frame work which is used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

Software Development Methodology (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, design, developement, testing, documentation, implementation and evaluation.

The art of Software Development requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is the software devlopers role to then communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

Software Development Methodolgies involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems and the time and resources required to implement the software.

3. Implementation
This is the time where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A tracibility matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of Software Development Methodolgies have evolved over the years.Each have its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of them are listed below.

1. Agile software development.
2. Waterfall model.
3. Spiral model.
4. Test-driven development (TDD).
5. Design-driven development (D3).

====General Problems faced during software development====

Software development process goes through the phases of Requirements, Design, Development, Testing & Maintenance one after the other. It relies on the dream that once a step is 100% complete, it is also 100% right and it drives us to the delivery of a working software even the one the customer wants. But it doesn’t go that way in the software industry: customers don’t know what they need and use to ask many useless features, project leaders don’t succeed to write down the perfect requirements, analysts spend ages building up software architectures writing down pages of diagrams – software is definitely one of the most complex artifact humans can build up – and developers are human too, so they make mistakes too. It is often very hard to create exactly what the customer wants in software development. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_lyfCycle.png|650px|thumb|center| Software development cycle.]]

====Solution : Agile Methodology====
“Agile” methodologies are a new way of developing the modular object-oriented software used for enterprise SOA. Agile programming breaks a project down into many mini-projects, instead of one huge “Big Bang.

The difference between Agile development and rest of methodologies can be related to the difference between a modern missile and a medieval cannonball. With the right information and calculations, the target of a cannonball could be accurately plotted. But once fired, there was no way of altering its trajectory. If the calculations were wrong, or if the target moved, it would miss. By contrast the modern missile can follow a given target with a series of incremental changes to its direction. It can even be given alternative targets when in flight, if the original is no longer appropriate.

[[Image:agile_vs_waterfall.jpg|650px|thumb|center| agile_vs_waterfall.]]

----

===How can Agile complement other development methodologies===
----

===Agile Vs waterFall===
----

===Conclusion===

----

===References===

[1]

----

File:Agile vs waterfall.jpg

2009-11-18T05:10:18Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T04:58:10Z

Vksingh: /* General Problems faced during software development */

Similar to the design pattern which give structure and name to commonly occuring problem, Software development methodology or system development methodology is a frame work which is used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

Software Development Methodology (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, design, developement, testing, documentation, implementation and evaluation.

The art of Software Development requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is the software devlopers role to then communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

Software Development Methodolgies involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems and the time and resources required to implement the software.

3. Implementation
This is the time where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A tracibility matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of Software Development Methodolgies have evolved over the years.Each have its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of them are listed below.

1. Agile software development.
2. Waterfall model.
3. Spiral model.
4. Test-driven development (TDD).
5. Design-driven development (D3).

====General Problems faced during software development====

Software development process goes through the phases of Requirements, Design, Development, Testing & Maintenance one after the other. It relies on the dream that once a step is 100% complete, it is also 100% right and it drives us to the delivery of a working software even the one the customer wants. But it doesn’t go that way in the software industry: customers don’t know what they need and use to ask many useless features, project leaders don’t succeed to write down the perfect requirements, analysts spend ages building up software architectures writing down pages of diagrams – software is definitely one of the most complex artifact humans can build up – and developers are human too, so they make mistakes too. It is often very hard to create exactly what the customer wants in software development. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_lyfCycle.png|650px|thumb|center| Software development cycle.]]

====Waterfall model====

====Prototyping====
====Incremental====
====Spiral====
====Rapid Application Development (RAD)====
====Agile====
----

===How can Agile complement other development methodologies===
----

===Agile Vs waterFall===
----

===Conclusion===

----

===References===

[1]

----

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T04:57:03Z

Vksingh: /* General Problems faced during software development */

Similar to the design pattern which give structure and name to commonly occuring problem, Software development methodology or system development methodology is a frame work which is used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

Software Development Methodology (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, design, developement, testing, documentation, implementation and evaluation.

The art of Software Development requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is the software devlopers role to then communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

Software Development Methodolgies involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems and the time and resources required to implement the software.

3. Implementation
This is the time where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A tracibility matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of Software Development Methodolgies have evolved over the years.Each have its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of them are listed below.

1. Agile software development.
2. Waterfall model.
3. Spiral model.
4. Test-driven development (TDD).
5. Design-driven development (D3).

====General Problems faced during software development====

Software development process goes through the phases of Requirements, Design, Development, Testing & Maintenance one after the other. It relies on the dream that once a step is 100% complete, it is also 100% right and it drives us to the delivery of a working software even the one the customer wants. But it doesn’t go that way in the software industry: customers don’t know what they need and use to ask many useless features, project leaders don’t succeed to write down the perfect requirements, analysts spend ages building up software architectures writing down pages of diagrams – software is definitely one of the most complex artifact humans can build up – and developers are human too, so they make mistakes too. It is often very hard to create exactly what the customer wants in software development. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_lyfCycle.png|650px|thumb|center| Milestone of version control development.]]

====Waterfall model====

====Prototyping====
====Incremental====
====Spiral====
====Rapid Application Development (RAD)====
====Agile====
----

===How can Agile complement other development methodologies===
----

===Agile Vs waterFall===
----

===Conclusion===

----

===References===

[1]

----

File:Software lyfCycle.png

2009-11-18T04:56:33Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T02:54:19Z

Vksingh: /* Introduction */

Similar to the design pattern which give structure and name to commonly occuring problem, Software development methodology or system development methodology is a frame work which is used to structure, plan, and control the process of developing an information system.

== '''Development methodologies''' ==

===Introduction===

Software Development Methodology (SDM) or Software Development Life Cycle (SDLC) is documented collection of policies, processes and procedures used to conduct a Software Engineering project. Software Engineering project involves various stages viz. analysis, design, developement, testing, documentation, implementation and evaluation.

The art of Software Development requires a clear understanding of the project or business goals by both the customer commissioning the project and the technical team. It is the software devlopers role to then communicate with the project sponsor and translate a business concept into a working software system in a timely and effective manner.

The use of systematic processes for the development of software reduces the risk that is inherent in any software project. These processes must be put in place in a careful manner to allow technical team members to solve problems in a creative and skillful manner.

Software Development Methodolgies involve following four key steps

1. Requirements
This is the phase where the Business Analyst or Project Manager works with the Customer to understand the project goals and translate this into a desired set of functional objectives.

2. Design
In this phase a solution is mapped out with 'pen and paper'. The solution describes how the final software will operate and includes other practical components including the technologies to be used, hardware requirements, impact on other information systems and the time and resources required to implement the software.

3. Implementation
This is the time where the agreed project plans are coded into a practical working system.

4. Testing
Testing is performed on discrete units of the computer system as well as the solution as a whole. A tracibility matrix can be used to ensure that each functional objective set in the requirements phase has been solved.

A wide variety of Software Development Methodolgies have evolved over the years.Each have its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Few of them are listed below.

1. Agile software development.
2. Waterfall model.
3. Spiral model.
4. Test-driven development (TDD).
5. Design-driven development (D3).

====General Problems faced during software development====

It is often very hard to create exactly what the customer wants in software development. Often the customer does not even knows what he wants, or it gets misinterpreted. With large software companies, the real ‘requirements’ can get mangled on so many levels. The below picture depicts it all:

[[Image:software_development_parties.jpg|650px|thumb|center| Milestone of version control development.]]

====Waterfall model====

====Prototyping====
====Incremental====
====Spiral====
====Rapid Application Development (RAD)====
====Agile====
----

===How can Agile complement other development methodologies===
----

===Agile Vs waterFall===
----

===Conclusion===

----

===References===

[1]

----

File:Software development parties.jpg

2009-11-18T02:50:37Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-18T02:18:42Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki3 7 Agile

2009-11-17T20:19:03Z

Vksingh:

A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.
== '''Development methodologies''' ==

----

===Introduction===

====Waterfall model====
====Prototyping====
====Incremental====
====Spiral====
====Rapid Application Development (RAD)====
====Agile====
----

===How can Agile complement other development methodologies===
----

===Agile Vs waterFall===
----

===Conclusion===

----

===References===

[1]

----

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:59:45Z

Vksingh: /* Conclusion */

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end

def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.

Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

===Conclusion===

Building patterns in Ruby is easier for a number of reasons:
#Ruby is dynamically typed. By dispensing with static typing, Ruby dramatically reduces the code overhead of building most programs, including those that implement patterns.
#Ruby has code closures. It allows us to pass around chunks of code and associated scope without having to laboriously construct entire classes and objects that do nothing else.
#Ruby classes are real objects. Because a class in Ruby is just another object, we can do any of the usual runtime things to a Ruby class that we can do to any other object: We can create totally new classes. We can modify existing classes by adding or deleting methods. We can even clone a class and change the copy, leaving the original alone.
#Ruby has an elegant system of code reuse.

In addition to supporting garden-variety inheritance, Ruby allows us to define mixins, which are a simple but flexible way to write code that can be shared among several classes. All of this makes code in Ruby compressible. In Ruby, as in Java and C++, you can implement very sophisticated ideas, but with Ruby it becomes possible to hide the details of your implementations much more effectively.

----

===See also===

----
[1] [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

[2] [http://en.wikipedia.org/wiki/Strategy_pattern Strategy]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer]

[4] [http://en.wikipedia.org/wiki/Composite_pattern Composite]

[5] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

[6] [http://en.wikipedia.org/wiki/Command_pattern Commands]

[7] [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]

[8] [http://en.wikipedia.org/wiki/Factory_method_pattern Factory]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:54:43Z

Vksingh: /* See also */

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end

def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.

Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

===Conclusion===

----
===See also===

----
[1] [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

[2] [http://en.wikipedia.org/wiki/Strategy_pattern Strategy]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer]

[4] [http://en.wikipedia.org/wiki/Composite_pattern Composite]

[5] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

[6] [http://en.wikipedia.org/wiki/Command_pattern Commands]

[7] [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]

[8] [http://en.wikipedia.org/wiki/Factory_method_pattern Factory]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:50:41Z

Vksingh: /* See also */

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end

def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.

Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

===Conclusion===

----
===See also===

----
[1] [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

[2] [http://en.wikipedia.org/wiki/Strategy_pattern Strategy]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer]

[4] [http://en.wikipedia.org/wiki/Composite_pattern Composite]

[5] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

[6] [http://en.wikipedia.org/wiki/Command_pattern Commands]

[7] [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]

[8] http://en.wikipedia.org/wiki/Factory_method_pattern Factory]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:49:38Z

Vksingh:

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end

def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.

Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

===Conclusion===

----
===See also===

----
[1] [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

[2] [http://en.wikipedia.org/wiki/Strategy_pattern Strategy]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer]

[4] [http://en.wikipedia.org/wiki/Composite_pattern Composite]

[5] [http://en.wikipedia.org/wiki/Iterator_pattern Iterator]

[6] [http://en.wikipedia.org/wiki/Command_pattern Commands]

[7] [http://en.wikipedia.org/wiki/Adapter_pattern Adapter]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:47:37Z

Vksingh:

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end

def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.

Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

===Conclusion===

----
===See also===

----
[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:44:57Z

Vksingh:

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end

def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.

Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

The GoF called this idea of building a clean interface between the source of the
news that some object has changed and the consumers of that news as "'''''the Observer pattern'''''"
(Refer above Figure).
The GoF called the class with the news as the '''''subject class'''''. In our example,
the subject class is the '''''Employee''''' class. '''''The observers''''' are the objects that are interested
in getting the news. In the above example, we have two observers which are '''''Payroll''''' '''''and'''''
'''''TaxMan'''''. Hence, when an object is interested in being informed of the state of the subject, it registers as an observer on that subject.

===Implementing the Observer pattern in Ruby===

===Conclusion===

----
===See also===

----
[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T22:39:22Z

Vksingh: /* [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] */

== '''Design patterns''' ==
The idea of design pattern was first introduced by the architect [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander] in the field of architecture. Later it has been adapted for various other disciplines, including computer science. Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context [1].

In general, a pattern has four essential elements:

#The '''pattern name''' is a handle used to describe a design problem, its solutions, and consequences in a word or two.
#The '''problem''' explains the problem and its context and also describes when to apply the pattern.
#The '''solution''' describes the elements that make up the design, their relationships, responsibilities, and collaborations.the pattern provides an abstract description of a design problem and how a general arrangement of elements solves it.
#The '''consequences''' are the results and trade-offs of applying the pattern.

A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. In software engineering, a design pattern is a solution to a general and commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. But it is a description or template for how to solve a problem that can be used in many different situations.

----

===Design patterns in ruby===
Almost every design patterns of ruby are borrowed from the [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 GOF] book. Following is the list of common pattern used in ruby.

#Template
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
#[http://en.wikipedia.org/wiki/Observer_pattern Observer]
#[http://en.wikipedia.org/wiki/Composite_pattern Composite]
#[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
#[http://en.wikipedia.org/wiki/Command_pattern Commands]
#[http://en.wikipedia.org/wiki/Adapter_pattern Adapter]
#Proxy
#[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
#Singleton
#Factory
#Builder
#[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]

===[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern]===

The essence of the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

[http://en.wikipedia.org/wiki/Factory_method_pattern Factory pattern] is used when

#a class can't anticipate the class of objects it must create.
#a class wants its subclasses to specify the objects it creates.
#classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. [1]

Will try to understand [http://en.wikipedia.org/wiki/Factory_method_pattern Factory] design pattern with the help of a real world problem. Imagine that we are asked to build a simulation of life in a pond. In particular, we need to model the comings and goings of the ducks. So we sit down and write a class to model the ducks:

Adapted from the class notes.

<pre>
class Duck
def initialize(name)
@name = name
end

def speak
puts("Duck #{@name} says Quack!")
end
end

</pre>

But ducks also need a place to live(Which we didn't implemented in class), and for that we build a Pond class:

<pre>
class Pond
def initialize(number_ducks)
@ducks = []
number_ducks.times do |i|
duck = Duck.new("Duck#{i}")
@ducks << duck
end
end

def simulate_one_day
@ducks.each {|duck| duck.speak}
end
end
</pre>

Life on the pond continues idyllically until one dark day when we get a request to model a different denizen of the puddle: the frog. Now it is easy enough to create a Frog class that sports exactly the same interface as the ducks:

<pre>
class Frog
def initialize(name)
@name = name
end

def speak
puts("Frog #{@name} says Crooooaaaak!")
end
end

</pre>

But there is a problem with the Pond class—right there in the initialize method we are explicitly creating '''ducks'''. And now we have exactly understood the problem which factory method solves.

Rewriting the factory adopted version of the Pound class.

<pre>
class Pond
def initialize(number_animals)
@animals = []
number_animals.times do |i|
animal = new_animal("Animal#{i}")
@animals << animal
end
end

def simulate_one_day
@animals.each {|animal| animal.speak}
end
end
</pre>

Next we can build two subclasses of Pond—one for a pond full of ducks and the other for a pond hopping with frogs:

<pre>
class DuckPond < Pond
def new_animal(name)
Duck.new(name)
end
end

class FrogPond < Pond
def new_animal(name)
Frog.new(name)
end
end
</pre>

And can happily use them as below

<pre>
pond = FrogPond.new(3)
pond.simulate_one_day
</pre>

----

===[http://en.wikipedia.org/wiki/Observer_pattern Observer pattern]===

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern](sometimes known as publish/subscribe) is a software design pattern in which an object, called the 'subject', maintains a list of its dependents, called 'observers', and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
 

The [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] is used when:
#An [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstraction] has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets us vary and reuse them independently. 
#A change to one object requires changing others, and we do not know how many objects need to be changed. 
#An object should be able to notify other objects without making assumptions about who these objects are. In other words, we don't want these objects tightly coupled. 
 
Example Scenario where Observer Pattern is Used: 
Consider a personnel system where an employee's salary changes and the payroll department needs to know when these changes take place. Here, How can one make the Employee object spread the news about salary changes without tangling it up with the payroll system?
In such a situation, Observer pattern is used. Initially, an object is created that is interested in the state of a person's(any employee's) finances. This object then needs to simply register with that person's 'Employee Object' ahead of time. Once registered, that object would receive timely updates about the ups and downs of the person's paycheck. 

Here is a basic version of an Employee object that tracks an employee. It does not have any code that tells about any salary updates. 
<pre>
class Employee
attr_reader :name
attr_accessor :title, :salary

def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
end
end
</pre>The employees can get raises because we made the salary field accessible with attr_accessor. 
<pre>
jim = Employee.new("Jim Flintstone", "Crane Operator", 5000.0)
# Give Jim a raise
jim.salary=8000.0
</pre>Now, adding some code to keep the payroll department informed of pay changes: 
<pre>
class Payroll
def update( changed_employee )
puts("Cut a new check for #{changed_employee.name}!")
puts("His salary is now #{changed_employee.salary}!")
end
end
</pre>
<pre>
class Employee
attr_reader :name, :title
attr_reader :salary
def initialize( name, title, salary,payroll)
@name = name
@title = title
@salary = salary
@payroll = payroll
end
def salary=(new_salary)
@salary = new_salary
@payroll.update(self)
end
end
</pre>
We can now change Jim's wages as follows: 
<pre>
payroll = Payroll.new
jim = Employee.new('Jim', 'Crane Operator', 5000, payroll)
jim.salary = 8000
</pre>
And the payroll department will know about these changes. The output of the above code is:
<pre>
Cut a new check for Jim!
His salary is now 8000!
</pre>
Improvising the above code: 
The trouble with the above code is that it is hard-wired to inform the payroll department alone about salary changes.
This does not help in the situations where some other classes for e.g.,accounting-related classes needs to be informed about
Jim's financial state. In such situation modifying employee class does not work out as nothing in the Employee class is really changing.
The general way to solve this problem is to separate out the thing that is changing. We can set up an array for list of objects(in the initialize method) that are interested in hearing about the latest news from the Employee object.
<pre>
def initialize( name, title, salary )
@name = name
@title = title
@salary = salary
@observers = []
end
</pre>
Also we need the following code to inform all of the observers that something has changed:
<pre>
def salary=(new_salary)
@salary = new_salary
notify_observers
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
</pre>
The key moving part of notify_observers is '''''observer.update(self)'''''. This bit of code calls the update method on each observer, telling it that something (in this case, the salary) has changed on the Employee object.
 

Now lets us consider writing methods that add and delete observers from the Employee object:
<pre>
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
</pre>

Putting all the pieces of the observer code discussed above :

<pre>
class Subject
def initialize
@observers=[]
end
def add_observer(observer)
@observers << observer
end
def delete_observer(observer)
@observers.delete(observer)
end
def notify_observers
@observers.each do |observer|
observer.update(self)
end
end
end

</pre>

And correspondingly the employee will inherit the subject as below:

<pre>
class Employee < Subject
attr_reader :name, :address
attr_reader :salary
def initialize( name, title, salary)
super()
@name = name
@title = title
@salary = salary
end
def salary=(new_salary)
@salary = new_salary
notify_observers
end
end
</pre>

Now any object that is interested in hearing about changes in Jim's salary can simply register as an observer on Jim's Employee object: 
<pre>
jim = Employee.new('Jim', 'Crane Operator', 5000.0)
payroll = Payroll.new
jim.add_observer( payroll )
jim.salary = 7000.0
</pre>
Hence by building this general mechanism, we have removed the implicit coupling between the Employee class and the Payroll object. Employee no longer cares which or how many other objects are interested in knowing about salary changes; it just forwards the news to any object that said that it was interested.
In addition, instances of the Employee class will be happy with no observers, one, or several observers.
<pre>

--figure--

 
Now the payroll department will hear about it:
<pre>
Cut a new check for Jim!
His salary is now 9000.0!
</pre>

The GoF called this idea of building a clean interface between the source of the
news that some object has changed and the consumers of that news as "'''''the Observer pattern'''''"
(Refer above Figure).
The GoF called the class with the news as the '''''subject class'''''. In our example,
the subject class is the '''''Employee''''' class. '''''The observers''''' are the objects that are interested
in getting the news. In the above example, we have two observers which are '''''Payroll''''' '''''and'''''
'''''TaxMan'''''. Hence, when an object is interested in being informed of the state of the subject, it registers as an observer on that subject.

===Implementing the Observer pattern in Ruby===

===Conclusion===

----
===See also===

----
[http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 Abstraction]

===References===
----

[1] [http://en.wikipedia.org/wiki/Gang_of_Four_%28software%29 Gang of Four]

[2] [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander]

[3] [http://en.wikipedia.org/wiki/Observer_pattern Observer Design pattern]

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T03:52:30Z

Vksingh: /* References */

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T03:49:23Z

Vksingh: /* Factory pattern */

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T03:44:58Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T03:21:12Z

Vksingh: /* Factory */

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T03:18:16Z

Vksingh: /* Factory */

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T02:25:25Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T02:03:21Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T01:05:33Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-09T01:01:21Z

Vksingh:

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-08T02:39:23Z

Vksingh:

Other design patterns in Ruby!

===Problem Statement===
What facilities does Ruby offer that makes it easier to realize other GoF (and other) patterns that we did not cover in class? The key idea here is to explore how Ruby can implement these patterns more efficiently or transparently than static (or other dynamic) o-o languages.

CSC/ECE 517 Fall 2009/wiki2 11 sv

2009-10-08T02:30:40Z

Vksingh:

Hello world

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

2009-09-17T03:00:30Z

Vksingh:

== '''History of version control''' ==

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is a [http://en.wikipedia.org/wiki/Utility_software software utility] used to manage data, especially ''source code'', within a [http://en.wikipedia.org/wiki/Software_development software development] environment. Managing changes are important for software engineers, since most of time they need to add, modify or fix a small portion of the code (also known as creating new version). Version control does the housekeeping of the changes by providing  a  detailed  history  of each document .  ''[http://en.wikipedia.org/wiki/Revision_control Version control]''  implements  several  techniques  to  ensure  the  integrity of  the  information,  while  making  use  of  minimal  resources.  This is a comprehensive list of [http://en.wikipedia.org/wiki/List_of_revision_control_software version control software].

----

===Introduction===

[http://en.wikipedia.org/wiki/Revision_control Version control] is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management  SCM]. Also  known  as  ''revision  control'', it acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allows multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to team  projects,   thereby enabling a  better  working  environment.  Keeping  records  of  all  changes  done to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

[http://en.wikipedia.org/wiki/Revision_control Version control] works  by  uniquely  identifying  each  piece  of  information  and  recording  the  changes  with  it.  The  information  is  stored  in  a  data repository,  an  information  database,  and  can  be  accessed  remotely  or  locally  depending  on  the  type  of  system.  When  a  user  is  required  to  make  changes  to  a  document, he  can  ''checkout'' the  corresponding file  from  the  system,  thus getting access to  the  most  up‐to‐date  version  of  it.  Once  the  file  has  been  amended,  the  user  can  then  commit and  re‐submit the  file,  updating  the  copy  in  the  repository , ready  for  use by other users.

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

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

Following are some issues requiring a Version Control System:

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''' : The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''' : The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

===History===
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]
====Change and Configuration Control (CCC)====
The history of Version control dates back to 1975 when [http://en.wikipedia.org/wiki/Software_configuration_management Software  Configuration  Management SCM] became commerical for the first time with the advent of CCC,which was developed by the SoftTool Corporation.CCC offered a central repository and provided a trunkery system that documented every change thus enhancing the accountability of the system and validity of the information stored.The changes were recorded as they occured,at regular intervals, during development and maintenance and at baseline release.

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions.In forward deltas the origin version is stored, all subsequent versions are stored as sets of changes or deltas where as in backword deltas, the most recent version is stored, all previous versions are stored as set [http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf |1|] Logically similar to [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS],it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site[http://catb.org/esr/writings/taoup/html/ch15s05.html |2|].

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

====Subversion(SVN)====
Perceived shortcomings and faults in [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by [http://en.wikipedia.org/wiki/CollabNet CollabNet Inc.] Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more. Distributed revision control took a peer-to-peer approach, as opposed to the client-server approach of centralized systems. The repository was split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  could  be  stored  on  servers  or  local  machines.This enabled every developer to edit his local sharable copy without having to connect to any network connection.Synchronization was conducted by exchanging patches (change-sets) from peer to peer.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized[http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ |3|].
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems, to being a part of Wiki too. Whether a waterfall, spiral, iterative, agile or open source approach is used, improvements to VCS technology have a direct impact on collaboration effectiveness. Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

===See Also===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]

[6] Ian Clatworthy, Distributed Version Control Systems – Why and How, [http://people.canonical.com/~ianc/papers/dvcs-why-and-how.xhtml Distributed Version Control System]

----

===References===

[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-12T11:49:26Z

Vksingh:

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

----

===Introduction===

[http://en.wikipedia.org/wiki/Revision_control Version control] is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management  SCM], also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

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

Following are some issues requiring a Version Control System:

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''' : The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''' : The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

===History===
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]
====Change and Configuration Control (CCC)====
The history of Version control dates back to 1975 when [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management SCM] became commerical for the first time with the advent of CCC,which was developed by the SoftTool Corporation.CCC offered a central repository and provided a trunkery system that documented every change thus enhancing the accountability of the system and validity of the information stored.The changes were recorded as they occured,at regular intervals, during development and maintenance and at baseline release.

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions.In forward deltas the origin version is stored, all subsequent versions are stored as sets of changes or deltas where as in backword deltas, the most recent version is stored, all previous versions are stored as set [http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf |1|] Logically similar to [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS],it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site[http://catb.org/esr/writings/taoup/html/ch15s05.html |2|].

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

====Subversion(SVN)====
Perceived shortcomings and faults in [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by [http://en.wikipedia.org/wiki/CollabNet CollabNet Inc.] Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository was split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  could  be  stored  on  servers  or  local  machines.This enabled every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized[http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ |3|].
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems, to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

===See Also===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]

----

===References===

[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-12T11:49:10Z

Vksingh:

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

2009-09-09T01:47:30Z

Vksingh: /* Introduction */

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

----

===Introduction===

[http://en.wikipedia.org/wiki/Revision_control Version control] is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management  SCM], also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

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

Following are some issues requiring a Version Control System:

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''' : The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''' : The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

===History===
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]
====Change and Configuration Control (CCC)====
The history of Version control dates back to 1975 when [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management SCM] became commerical for the first time with the advent of CCC,which was developed by the SoftTool Corporation.CCC offered a central repository and provided a trunkery system that documented every change thus enhancing the accountability of the system and validity of the information stored.The changes were recorded as they occured,at regular intervals, during development and maintenance and at baseline release.

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS],it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by [http://en.wikipedia.org/wiki/CollabNet CollabNet Inc.] Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository was split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  could  be  stored  on  servers  or  local  machines.This enabled every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems, to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

===See Also===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T01:11:24Z

Vksingh: /* History */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM), also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

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

Following are some issues requiring a Version Control System:

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

===History===
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]
====Change and Configuration Control (CCC)====
The history of Version control dates back to 1975 when [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM) became commerical for the first time with the advent of CCC,which was developed by the SoftTool Corporation.CCC offered a central repository and provided a trunkery system that documented every change thus enhancing the accountability of the system and validity of the information stored.The changes were recorded as they occured,at regular intervals, during development and maintenance and at baseline release.

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS],it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository was split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  could  be  stored  on  servers  or  local  machines.This enabled every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T01:02:05Z

Vksingh: /* Change and Configuration Control (CCC) */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM), also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

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

Following are some issues requiring a Version Control System:

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

===History===
====Change and Configuration Control (CCC)====
The history of Version control dates back to 1975 when [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM) became commerical for the first time with the advent of CCC,which was developed by the SoftTool Corporation.CCC offered a central repository and provided a trunkery system that documented every change thus enhancing the accountability of the system and validity of the information stored.The changes were recorded as they occured,at regular intervals, during development and maintenance and at baseline release.

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS],it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository was split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  could  be  stored  on  servers  or  local  machines.This enabled every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:41:09Z

Vksingh: /* Introduction */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM), also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:40:40Z

Vksingh: /* Introduction */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM), also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System(SCCS)====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model where in only one person could check out and edit a file at one time.This led to serialized development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface and good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:34:00Z

Vksingh: /* Introduction */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM), also  known  as  ''revision  control'' and acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

<pre> While [http://en.wikipedia.org/wiki/File_system file systems] provide operations like open, save, rename and delete, version control systems provide checking-in and checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision
from the system.</pre>

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model to serialize development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:30:28Z

Vksingh: /* Introduction */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM), also  known  as  ''revision  control''. It acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

<pre> While [http://en.wikipedia.org/wiki/File_system file systems] provide operations like open, save, rename and delete, version control systems provide checking-in and checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision
from the system.</pre>

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model to serialize development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]
----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:20:50Z

Vksingh: /* Introduction */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM).It is also  known  as  ''revision  control'',  and  acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

<pre> While [http://en.wikipedia.org/wiki/File_system file systems] provide operations like open, save, rename and delete, version control systems provide checking-in and checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision
from the system.</pre>

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep track of what changes are made in the code, why they are made and who made them. A VCS enables change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': The ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': The ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model to serialize development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It worked  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a [http://en.wikipedia.org/wiki/Patch_(Unix) diff] or a [http://en.wikipedia.org/wiki/Patch_(Unix) patchfile].

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:10:36Z

Vksingh: /* Issues Version Control addressed */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM).It is also  known  as  ''revision  control'',  and  acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep a track of what changes are made in the code, why they are made and who made them. A VCS enables Change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': the ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': the ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model to serialize development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It works  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a diff or a patchfile.

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----

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

2009-09-09T00:09:51Z

Vksingh: /* Introduction */

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

----

===Introduction===

''[http://en.wikipedia.org/wiki/Revision_control Version control]'' is  a  fundamental  part  of  [http://en.wikipedia.org/wiki/Software_configuration_management software  configuration  management] (SCM).It is also  known  as  ''revision  control'',  and  acts  as  a  key  lifeline  in  a  team  environment. Version  control  works  by  keeping  a  record  of  every  unit  of  information  and  tracks  the  changes  and  updates  made. 

It also  allow multiple  users  to  edit  the  same  document  at  the  same  time. This provides a  valuable  resource  to the team  projects,  and  thereby enables a  better  working  environment.  Keeping  records  of  all  changes  to  a  set  of  information  provides  a  reliable  solution  to  data  management,  and  an  archive  for  future reference. 

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

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

[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]

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

====Issues Version Control addressed====

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

* '''Change tracking''' : While working in a team project it gets difficult to keep a track of what changes are made in the code, why they are made and who made them. A VCS enables Change tracking by documenting every change with all the requisite details.
* '''Reversion''' : At times changes in a particular code module can lead to the entire application failing during regression testing
and calls for reversion to a code version that is known good. If reversion is difficult or unreliable, it's hard to risk making changes at all.
* '''Bug tracking''' : In an agile software development environment it's quite common to get new bug reports for a particular version after the code has mutated away from it considerably.But when the bug doesn't reproduce under the new version, it gets difficult to know whether it still exists or has been fixed already. Under such circumstances it calls for getting back to the older version of the code in order to reproduce and comprehend it.
* '''Concurrency''': the ability to have many people across separate geographic locations modifying the same collection of files knowing that conflicting modifications can be detected and resolved.
* '''History''': the ability to attach historical data to your data, such as explanatory comments about the intention behind each change to it. Even for a programmer working solo, change histories are an important aid to memory; for a multi-person project, they are a vitally important form of communication among developers.

----

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

====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====
Then came the [http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS] which was developed by M. J Rochkind in the very early 1970’s. Designed basically for a unix system, it provided a simple locking model to serialize development.Based on a central repository it used the notion of discrete delta to record changes which were combined and reconstructed to produce the final version of the product.

====Diff Algorithm====
The  [http://en.wikipedia.org/wiki/Diff diff  algorithm ]  was developed  by  AT&T  [http://en.wikipedia.org/wiki/Bell_Labs Bell  Labs]  in  1974,  and  prototyped  by  James  W.  Hunt  in  1976.   It works  by  finding  the  [http://en.wikipedia.org/wiki/Longest_common_subsequence_problem longest  common  subsequence],  then  comparing  the  data  preceding and  following it, incorporating the changes in a diff or a patchfile.

====Revsion Control System(RCS)====
In the early 1980’s Walter Tichy introduced the [http://en.wikipedia.org/wiki/Revision_Control_System RCS]. [http://en.wikipedia.org/wiki/Revision_Control_System RCS] introduced both forward and reverse delta concepts for efficient storage of different file revisions. Logically similar to SCCS,it has a cleaner command interface good facilities for grouping together entire project releases under symbolic names.It is well suited for single-developer or small-group projects hosted at a single development site.

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

====Subversion(SVN)====
Perceived shortcomings and faults in CVS eventually led to a new version control system called [http://en.wikipedia.org/wiki/Subversion_(software) SVN] around 2001.It was developed by CollabNet Inc. Unlike [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], [http://en.wikipedia.org/wiki/Subversion_(software) SVN] committed changes atomically and significantly had better support for branches.

====Distributed Version Control====
The paradigm then shifted from client server architecture to a [http://en.wikipedia.org/wiki/Distributed_revision_control distributed system] around 2001, with the development of systems like [http://en.wikipedia.org/wiki/SVK SVK], [http://en.wikipedia.org/wiki/BitKeeper Bitkeeper], [http://en.wikipedia.org/wiki/Mercurial_(software) Mercurial], [http://en.wikipedia.org/wiki/GNU_arch GNU Arch], [http://en.wikipedia.org/wiki/Darcs DARCS], [http://en.wikipedia.org/wiki/Git_(software) GIT], [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/Monotone_(software) monotone], [http://en.wikipedia.org/wiki/Codeville codeville], [http://en.wikipedia.org/wiki/Vesta_(Software_configuration_management) Vesta] , [http://en.wikipedia.org/wiki/Aegis_(management_software) Aegis] and many more.In all these the repository is split into several s sub‐repositories  for  each  section  or  module  of  a  project. The  sub‐repositories  can  be  stored  on  servers  or  local  machines.This enables every developer to edit his local sharable copy without having to connect to any network connection.

A detailed comparision of all the Version Control Systems till date can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here]
----

===Big Shift in Paradigm===
The traditional Version Control Systems were based on a Client Server Model. It is a simple and easy to use model that uses a central repository that is accessible to all the users allowing them to get an up-to-date version instantly. It works for backup, undo and synchronization but has the following drawbacks:
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.
#Peer to Peer synchronization is not supported.
#Offline commits is not supported as all operations occur through a connection to a centralized server.
#Data back up is not adequate as there is a single repository.
#Performance is slow.

In order to overcome the drawbacks inherent in the Centralized Model,most of the recent Version Control Systems adopted a Distributed model that has several clones of the main repository, each downloaded to a local machine for use by a single user, instead of a single repository.It offers the following advantages-
#More flexible as, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized.
#Provides the users unlimited access to the repository even when they are not connected to the network.
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.
#It has better merging and branching capabilities.
#Information is more secure as each local repository acts as a backup of the central repository.
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.

Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].

----

===Conclusion===
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [http://en.wikipedia.org/wiki/Word_processor word processors] (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Writer OpenOffice.org Writer], [http://en.wikipedia.org/wiki/Microsoft_Word Microsoft Word], [http://en.wikipedia.org/wiki/KOffice KOffice], [http://en.wikipedia.org/wiki/Pages Pages], [http://en.wikipedia.org/wiki/Google_Docs Google Docs]), spreadsheets (e.g. [http://en.wikipedia.org/wiki/OpenOffice.org_Calc OpenOffice.org Calc], [http://en.wikipedia.org/wiki/Google_Spreadsheets Google Spreadsheets], [http://en.wikipedia.org/wiki/Microsoft_Excel Microsoft Excel]), and in various content management systems to being a part of Wiki too.Overall it can be said that versioning systems are powerful development management tools that provide security, eﬃciency and most importantly an asynchronous platform for software development.

----

=== Useful Seminal Papers===
[1] Vincenzo Ambriola, Lars Bendix and Paolo Ciancarini , Software Engineering Journal November 1990 [http://bneal.co.uk/papers/version_control.pdf The evolution of configuration management and version control]

[2] Benjamin  Neal,ECM 3406  Dissertation 11th  December  2008  , [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=61744&isnumber=2248 Version  Control:An  Overview]

 [3] Bryan O'Sullivan, ACM 2009, [http://portal.acm.org/citation.cfm?id=1594204.1595636&coll=GUIDE&dl=GUIDE&CFID=50565619&CFTOKEN=27688531 Making Sense of Revision-control Systems]

[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control]

----

===External links===

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

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

[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/

----