https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=AfouzdaExpertiza_Wiki - User contributions [en]2026-07-13T07:13:52ZUser contributionsMediaWiki 1.41.0https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=29785CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-20T00:31:43Z<p>Afouzda: </p>
<hr />
<div></div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_17_am&diff=29784CSC/ECE 517 Fall 2009/wiki3 17 am2009-11-20T00:30:41Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.<br />
<br />
The graphics system given above can be reimplemented in the Object Oriented Manner as:<br />
<br />
<pre><br />
class SHAPE<br />
display_details<br />
end<br />
end<br />
<br />
class CIRCLE < SHAPE<br />
display_details<br />
print "Circle. r=" + radius;<br />
end<br />
end<br />
<br />
class SQUARE < SHAPE<br />
display_details<br />
print "Square. sides=" + sideLength;<br />
end<br />
end<br />
<br />
class RECTANGLE < SHAPE<br />
display_details<br />
print "Rect. h=" + height + " w=" + width;<br />
end<br />
end <br />
</pre> <br />
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.<br />
<br />
===Other Highlights===<br />
# According to the Single Choice principle exactly one module should know the list of choices, which contrasts the modularity goal which suggests that <i>at most one</i> module should have this knowledge.<br />
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.<br />
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].<br />
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.<br />
<br />
===Conclusion===<br />
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].<br />
<br />
===References===<br />
# Object-Oriented Software Construction Second Edition, Bertrand Meyer pg 62-64.<br />
# [http://c2.com/cgi/wiki?SingleChoicePrinciple Single Choice Principle]</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_17_Single_Choice_Pattern_am&diff=29783CSC/ECE 517 Fall 2009/wiki3 17 Single Choice Pattern am2009-11-20T00:10:59Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.<br />
<br />
The graphics system given above can be reimplemented in the Object Oriented Manner as:<br />
<br />
<pre><br />
class SHAPE<br />
display_details<br />
end<br />
end<br />
<br />
class CIRCLE < SHAPE<br />
display_details<br />
print "Circle. r=" + radius;<br />
end<br />
end<br />
<br />
class SQUARE < SHAPE<br />
display_details<br />
print "Square. sides=" + sideLength;<br />
end<br />
end<br />
<br />
class RECTANGLE < SHAPE<br />
display_details<br />
print "Rect. h=" + height + " w=" + width;<br />
end<br />
end <br />
</pre> <br />
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.<br />
<br />
===Other Highlights===<br />
# According to the Single Choice principle exactly one module should know the list of choices, which contrasts the modularity goal which suggests that <i>at most one</i> module should have this knowledge.<br />
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.<br />
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].<br />
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.<br />
<br />
===Conclusion===<br />
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].<br />
<br />
===References===<br />
# Object-Oriented Software Construction Second Edition, Bertrand Meyer pg 62-64.<br />
# [http://c2.com/cgi/wiki?SingleChoicePrinciple Single Choice Principle]</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27658CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:45:59Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===<br />
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27657CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:43:16Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===<br />
The single choice principle is a principle of imperative computer programming.It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to polymorphism and aims at achieving high cohesion and low coupling, one of the most important aspects of Modularity.</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27656CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:42:48Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===<br />
The single choice principle is a principle of imperative computer programming.It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to polymorphism and aims at achieving high cohesion and low coupling, one of the most important aspect of Modularity.</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27631CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:26:50Z<p>Afouzda: /* Introduction */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27629CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:25:46Z<p>Afouzda: /* Introduction */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the Don't repeat yourself principle.<br />
<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27619CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:18:48Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27608CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T21:01:11Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===<br />
===Conclusion===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27606CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:53:56Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of SCP===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.<br />
<br />
===Implementation of SCP===<br />
===Other Highlights===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27604CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:50:07Z<p>Afouzda: /* Violation of Single Choice Principle */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of Single Choice Principle===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
<pre>For example old style procedural code to print different "shape" objects might read:<br />
<br />
if (type==CIRCLE)<br />
print "Circle. r=" + radius;<br />
else if (type==Square)<br />
print "Square. sides=" + sideLength;<br />
else if (type==Rectangle)<br />
print "Rect. h=" + height + " w=" + width;<br />
endif</pre> <br />
<br />
This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape. <br />
<br />
*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27580CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:36:54Z<p>Afouzda: /* Violation of Single Choice Principle */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of Single Choice Principle===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -<br />
<br />
* In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.<br />
* In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.<br />
* In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27578CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:34:23Z<p>Afouzda: /* Violation of Single Choice Principle */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of Single Choice Principle===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:...Instructions which may access the field p.publisher<br />
journal:...Instructions which may access fields p.volume,p.issue<br />
proceedings:...Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27575CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:33:28Z<p>Afouzda: /* Violation of Single Choice Principle */</p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of Single Choice Principle===<br />
<br />
Consider a type used to manage a declared in Pascal-Ada syntax : <br />
<pre>Type Publication=<br />
record<br />
author,title:STRING;<br />
publication_year:INTEGER;<br />
case pubtype: (book,journal,conference_proceedings)of<br />
book: (publisher:STRING);<br />
journal: (volume,issue:STRING);<br />
proceedings: (editor, place:STRING) – Conference proceedings<br />
end</pre><br />
Let B be a typical client of A. B will manipulate publications through a variable such as <br />
p:PUBLICATION<br />
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:<br />
<pre> case p of <br />
book:..Instructions which may access the field p.publisher<br />
journal:..Instructions which may access fields p.volume,p.issue<br />
proceedings:..Instructions which may access fields p.editor,p.place<br />
end</pre><br />
<br />
Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.<br />
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for eg.,<br />
• I</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27573CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:30:40Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Principle'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.<br />
===Violation of Single Choice Principle===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27572CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:29:14Z<p>Afouzda: /* Introduction */</p>
<hr />
<div>=='''Single Choice Pattern'''==<br />
===Introduction===<br />
<br />
Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules.</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27571CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:28:47Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Pattern'''==<br />
===Introduction===</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_Single_Choice_Pattern_am&diff=27570CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am2009-11-17T20:28:13Z<p>Afouzda: </p>
<hr />
<div>=='''Single Choice Pattern'''==</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19200CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T19:27:48Z<p>Afouzda: /* See Also */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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].<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
[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]<br />
<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19199CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T19:25:32Z<p>Afouzda: /* See Also */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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].<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
[6]Ian Clatworthy, Distributed Version Control Systems – Why and How, [http://people.canonical.com/~ianc/papers/dvcs-why-and-how.xhtml]<br />
<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19198CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T19:23:24Z<p>Afouzda: /* Distributed Version Control */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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].<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19197CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T19:22:58Z<p>Afouzda: /* Distributed Version Control */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19196CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T19:18:52Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19195CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T18:57:52Z<p>Afouzda: /* Change and Configuration Control (CCC) */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19194CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T18:52:24Z<p>Afouzda: /* Introduction */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19193CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T18:39:08Z<p>Afouzda: /* Introduction */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19192CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T18:37:46Z<p>Afouzda: /* Introduction */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19191CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T18:35:19Z<p>Afouzda: </p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19190CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-15T18:33:47Z<p>Afouzda: </p>
<hr />
<div>''[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 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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19149CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-13T22:24:38Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19148CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-13T22:23:58Z<p>Afouzda: </p>
<hr />
<div>''[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].<br />
<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=19065CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-12T04:11:51Z<p>Afouzda: </p>
<hr />
<div>''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
[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. <br />
<br />
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. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and <br />
checking-out.Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file<br />
revision from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
The basic purpose of a Version Control System was to maintain different versions of a file.<br />
<br />
Following are some issues requiring a Version Control System:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
[[Image:History.jpg|650px|thumb|center| Milestone of version control development.]]<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System(SCCS)====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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].<br />
<br />
====Revsion Control System(RCS)====<br />
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 <sup>|1|</sup>] 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 <sup>|2|</sup>].<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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/ <sup>|3|</sup>].<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
===See Also===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
[5] Marc J. Rochkind, IEEE Transactions on Software Engineering December 1975, [http://basepath.com/aup/talks/SCCS-Slideshow.pdf The Source Code Control System]<br />
<br />
----<br />
<br />
===References===<br />
<br />
[1] http://www.cs.colorado.edu/~kena/classes/3308/f03/lectures/lecture12.pdf<br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ <br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18673CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T13:15:34Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== Useful Seminal Papers===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18652CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:40:41Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
[4] Löh, A., Swierstra, W., Leijen, D. 2007, [http://people.cs.uu.nl/andres/VersionControl.html A principled approach to version control] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18651CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:37:51Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18650CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:37:42Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18649CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:37:30Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
[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]<br />
]<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18648CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:37:18Z<p>Afouzda: /* References */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
[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<br />
]<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18645CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:29:41Z<p>Afouzda: /* Big Shift in Paradigm */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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.<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18644CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:29:18Z<p>Afouzda: /* Big Shift in Paradigm */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported as all operations occur through a connection to a centralized server.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#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<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18643CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T05:23:09Z<p>Afouzda: /* External links */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
[3] http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18635CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:52:09Z<p>Afouzda: /* Big Shift in Paradigm */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
Detailed explanation of the two models with an analogy can be found [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ here].<br />
<br />
----<br />
<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18634CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:49:36Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
===Conclusion===<br />
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, efficiency and most importantly an asynchronous platform for software development.<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18632CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:43:42Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
===Conclusion===<br />
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [word processors] (e.g. [OpenOffice.org Writer], [Microsoft Word], [[KOffice]], Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18631CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:42:46Z<p>Afouzda: /* Conclusion */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
===Conclusion===<br />
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [[word processors]] (e.g. [[OpenOffice.org Writer]], Microsoft Word, KOffice, Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18630CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:40:56Z<p>Afouzda: /* Big Shift in Paradigm */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
===Conclusion===<br />
Version Control is becoming a standard with most areas in the computer arena from being embedded into various types of softwares like [[word processor]]s (e.g. [[OpenOffice.org Writer]], [[Microsoft Word]], [[KOffice]], [[Pages]], [[Google Docs]]), spreadsheets (e.g. [[OpenOffice.org Calc]], [[Google Spreadsheets]], [[Microsoft Excel]]), and in various [[content management system]]s<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18628CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:29:12Z<p>Afouzda: /* Solution to these */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18627CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:28:49Z<p>Afouzda: /* Why it was necessary */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
<br />
===Solution to these===<br />
<br />
How they solved these problem.<br />
----<br />
<br />
<br />
<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzdahttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_5_History_of_version_control_by_av&diff=18626CSC/ECE 517 Fall 2009/wiki1a 5 History of version control by av2009-09-08T04:26:49Z<p>Afouzda: /* Change in Paradigm */</p>
<hr />
<div>''[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 the changes are important for software engineers, since during most of time they need to add, modify or fix a small portion of the code (also known as version). And version control does the housekeeping of the changes by providing a detailed history of each document . ''[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].<br />
<br />
----<br />
<br />
===Introduction===<br />
<br />
''[http://en.wikipedia.org/wiki/Revision_control Version control]'', also known as ''revision control'', is a fundamental part of [http://en.wikipedia.org/wiki/Software_configuration_management software configuration management] (SCM), and acts as a key lifeline in a team environment. Version control works by keeping a record of every unit of information and tracks the changes and updates made. <br />
<br />
It also allows for multiple users to edit the same document at the same time, providing a valuable resource for team projects, and enabling a better working environment. Keeping records of all changes to a set of information provides a fail‐safe solution to data management, and an archive for subsequent reference. <br />
<br />
[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.<br />
<br />
<br />
<pre> While file systems provide operations like open, save, rename and delete, version control systems provide checking-in and<br />
checking-out. Like their file system counterparts checking-in stores a file version, and checking-out retrieves a file revision<br />
from the system.</pre> <br />
<br />
[[Image:Svn.png|650px|thumb|center|A typical history of a file version in [http://en.wikipedia.org/wiki/Subversion_%28software%29 SVN].]]<br />
<br />
<span style="color: #33FF00"> '''Trunk''' </span> is the main copy of a project on which development progresses. Team members create <br />
<span style="color: #FFCC33 "> '''branches''' </span> (Similar to fork) from the <span style="color: #33FF00"> '''Trunk''' </span> and work on that copy.This provides the flexibility to modify the document in parallel along both <span style="color: #FFCC33 "> '''branches''' </span>. At the end changes are <span style="color: #FF0000 "> '''merged''' </span> to the <span style="color: #33FF00"> '''Trunk''' </span>, and this process continues.<br />
<br />
<br />
<br />
====Issues Version Control addressed====<br />
<br />
Following were some of reasons version control was developed to address . <br />
<br />
* '''Change tracking''' : It's easy to forget the reasons for changes and step on them later. If you have collaborators on a project, how do you know what they have changed while you weren't looking, and who was responsible for each change?<br />
* '''Reversion''' : If you make a change, and discover it's not viable, how can you revert to a code version that is known good? If reversion is difficult or unreliable, it's hard to risk making changes at all (you could trash the whole project, or make many hours of painful work for yourself).<br />
* '''Bug tracking''' : It's quite common to get new bug reports for a particular version after the code has mutated away from it considerably. Sometimes you can recognize immediately that the bug has already been stomped, but often you can't. Suppose it doesn't reproduce under the new version. How do you get back the state of the code for the old version in order to reproduce and understand it?<br />
* '''Concurrency''': the ability to have many people modifying the same collection of files knowing that conflicting modifications can be detected and resolved.<br />
* '''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. <br />
<br />
<br />
<br />
<br />
<br />
----<br />
<br />
===History===<br />
====Change and Configuration Control (CCC)====<br />
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.<br />
<br />
====Source Code Control System([http://en.wikipedia.org/wiki/Source_Code_Control_System SCCS])====<br />
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.<br />
<br />
====Diff Algorithm====<br />
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.<br />
<br />
====Revsion Control System(RCS)====<br />
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.<br />
<br />
====Concurrent Version System(CVS)====<br />
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.<br />
<br />
====Subversion(SVN)====<br />
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.<br />
<br />
====Distributed Version Control====<br />
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.<br />
<br />
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]<br />
----<br />
<br />
===Big Shift in Paradigm===<br />
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:<br />
#Branching and Merging is cumbersome.Users have to manually track revisions between merged branches.<br />
#Peer to Peer synchronization is not supported.<br />
#Offline commits is not supported.<br />
#Data back up is not adequate as there is a single repository.<br />
#Performance is slow.<br />
<br />
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-<br />
#Provides the users unlimited access to the repository even when they are not connected to the network.<br />
#Supports Peer to Peer Synchronization as the users rely on a group of users rather than a central entity.<br />
#It has better merging and branching capabilities.<br />
#Information is more secure as each local repository acts as a backup of the central repository.<br />
#Speed of execution of commands as well as viewing transaction and error reports is fast as no network connection is involved.<br />
<br />
----<br />
<br />
===Solution to these===<br />
<br />
How they solved these problem.<br />
----<br />
<br />
===Why it was necessary===<br />
<br />
<br />
----<br />
<br />
=== References===<br />
[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]<br />
<br />
[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] <br />
<br />
<br />
----<br />
<br />
===External links===<br />
<br />
[1] http://agave.garden.org/~aaronh/rcs/manual/html/ch05.html <br />
<br />
[2] http://catb.org/esr/writings/taoup/html/ch15s05.html<br />
<br />
<br />
----</div>Afouzda