-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathIntroduction_Old.tex
More file actions
13 lines (7 loc) · 3.33 KB
/
Copy pathIntroduction_Old.tex
File metadata and controls
13 lines (7 loc) · 3.33 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
\section{Introduction}
Subversion Control is a means by which a number of people can collaboratively work upon a collection of documents. It allows each individual to work on any document within a collection of documents at the same time as the other members of the project team.
If one is working with a team of people on a large project, say the design of a oil fired boiler. Then there would be a lot of documentation that tends to overlap. For example the design of the boiler would affect the layout of the various utilities, feed lines and product/exhaust lines. As some one adjusts something in the layout of the fuel feed line it would affect the layout of say the emergency fire water system. This information would have to be recorded in the relevant documentation of both systems.
One would expect that person A who is adjusting the fuel line documentation would also want adjust the relevant sections in the emergency fire water system documentation at the same time. However person B is presently adjusting the same documentation but under some other section, lets say B is describing how emergency response teams are to respond under various scenarios. So if A and B worked on the same file at the same time their work would not affect one another as they are each editing different sections of the same document.
Let both A and B get a copy of the original file they would edit their relevant sections and then save the files again. If A finished first his file would replace the original file. Now when B saves his file he would overwrite the work that A did since he is still using the original file, which does not include the additional work done by A. To prevent this one could lock the file so that when A is modifying it, then B can only view the file but he cannot edit it. Only once A is complete will B be able to insert the relevant changes s/he wishes to make.
This is an inefficient solution though since B wishes to work on a completely different section of the same document. It is more efficient to let both A and B work upon the original document and then combine their efforts into a new file that would then replace the original file. This is the intention of subversion control. Each person obtains a subversion of the original file which they may edit separately and then combine at a later time.
In centralized subversion control the entire project would be stored in one location. Individuals may then access, modify and later update this central version. Now lets assume a group of people would like to work on developing an entirely new section of the project and that the section needs to be included as one large addition versus having a number of minor additions made by individuals. It would make sense to let this group develop this section amongst themselves without having to refer to the main copy of the project. Here the collaboration within the group becomes more significant then the contribution of each individual. One would then prefer that the group develop this section independently of what is on the centralized copy of the project and commit the change only when the group is happy that it is complete. This gives motivation for decentralized subversion control where by the individual groups may then maintain their own copy of the central project, edit it as they wish and only when they are happy with the change add it to the central copy.