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