← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/purpose.txt

  • Committer: Eric Holmberg
  • Date: 2008-05-06 15:02:27 UTC
  • mto: This revision was merged to the branch mainline in revision 3449.
  • Revision ID: eholmberg@arrow.com-20080506150227-l3arq1yntdvnoxum
Fix for Bug #215426 in which bzr can cause a MemoryError in socket.recv while
downloading large packs over http.  This patch limits the request size for
socket.recv to avoid this problem.

Changes:
Added mock file object bzrlib.tests.file_utils.
Added new parameters to bzrlib.osutils.pumpfile.
Added unit tests for bzrlib.osutils.pumpfile.
Added usage of bzrlib.osutils.pumpfile to bzrlib.transport.http.response.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/purpose.txt
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.
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
 
 
77
 
    * The ability of a developer to checkpoint changes to a module and
78
 
      to back off to a previous version of that module