|
6
by mbp at sourcefrog
import all docs from arch |
1 |
What is the purpose of version control? |
2 |
*************************************** |
|
3 |
||
4 |
There are several overlapping purposes: |
|
5 |
||
6 |
* Allowing concurrent development by several people. Primarily, |
|
7 |
helping resolve changes when they are integrated, but also making |
|
8 |
each person aware of what the others have been doing, allowing them |
|
9 |
to talk about changes, etc. |
|
10 |
||
11 |
* To allow different lines of development, with sensible |
|
12 |
reintegration. e.g. stable/development, or branches for |
|
13 |
experimental features. |
|
14 |
||
15 |
* To record a history of development, so that you can find out why a |
|
16 |
feature went in or who added it, or which releases might be affected |
|
17 |
by a bug. |
|
18 |
||
19 |
* In particular, as a *record of decisions* about the project made by |
|
20 |
the developers. |
|
21 |
||
22 |
* Help in writing a gloss on that history; not simply a record of |
|
23 |
events but an explanation of what happened and why. Such a record |
|
24 |
may need to be written at several levels: a very detailed |
|
25 |
explanation of changes to a function; a note that a bug was fixed |
|
26 |
and why; and then a brief NEWS file for the whole release. |
|
27 |
||
28 |
While past events can never change, the intepretation placed upon |
|
29 |
them may change, even after the event. For example, even after a |
|
30 |
release has gone out, one might want to go back and note that a bug |
|
31 |
was actually fixed. |
|
32 |
||
33 |
The system is helping the developers tell a story about the |
|
34 |
development of the project. |
|
35 |
||
36 |
* As an aid to thinking about the project. (Much as a personal |
|
37 |
journal is not merely a record or even analysis of events, but also |
|
38 |
a chance to reflect and to think of the future.) |
|
39 |
||
40 |
People can review diffs, and then write a description of what |
|
41 |
changed, and in doing so perhaps realize something else they should |
|
42 |
do, or realize they made a mistake. Making branches helps work out |
|
43 |
the order of feature integration and the stability of different |
|
44 |
lines of development. |
|
45 |
||
46 |
* As an 'undo' protection mechanism. This is one reason why version |
|
47 |
control can be useful on projects that have only a single developer |
|
48 |
and never branch. |
|
49 |
||
50 |
* Incidentally, as a backup mechanism. Version control systems, |
|
51 |
particularly distributed systems, tend to cause code to exist on |
|
52 |
several machines, which gives some protection against loss of any |
|
53 |
single copy. It's still a good idea to use a separate backup system |
|
54 |
as well. |
|
55 |
||
56 |
* As a file-sharing mechanism: even with just a single developer and |
|
57 |
line of development it can be useful to keep files synchronized |
|
58 |
between several machines, which may not always be connected. |
|
|
35
by Martin Pool
Notes from Steve Berczuk on purpose of SCM |
59 |
|
60 |
||
61 |
---- |
|
62 |
||
63 |
Steve Berczuk says__: |
|
64 |
||
65 |
__ http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ConfigurationManagementPatterns |
|
66 |
||
67 |
A successful configuration management process allows: |
|
68 |
||
69 |
* Developers to work together on a project, sharing common code. |
|
70 |
||
71 |
* Developers to share development effort on a module. |
|
72 |
||
73 |
* Developers to have access to the current stable (tested) version of a system. |
|
74 |
||
75 |
* The ability to back up to a previous stable version (one of a number of NamedStableBases), of a system |
|
76 |
||
|
52
by mbp at sourcefrog
fixup doctest for new module structure |
77 |
* The ability of a developer to checkpoint changes to a module and |
78 |
to back off to a previous version of that module |