← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ru/user-guide/zen.txt

  • Committer: Robert Collins
  • Date: 2007-11-18 19:56:39 UTC
  • mfrom: (3006 +trunk)
  • mto: This revision was merged to the branch mainline in revision 3038.
  • Revision ID: robertc@robertcollins.net-20071118195639-m6zf3d5ljjw88kkn
Merge bzr.dev.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ru/user-guide/zen.txt
1
 
Путь Bazaar
2
 
===========
3
 
 
4
 
Глубокое понимание Bazaar
5
 
-------------------------
6
 
 
7
 
Хотя Bazaar во многом похож на другие инструменты контроля версий, есть
8
 
некоторые важные различия, которые не всегда очевидны на первый взгляд. Этот
9
 
раздел пытается объяснить некоторые вещи, который пользователь должен знать
10
 
чтобы разбираться в Bazaar, т.е. глубоко его понимать.
11
 
 
12
 
Заметьте: чтобы использовать Bazaar совсем необязательно полностью понимать
13
 
этот раздел. Вы можете просмотреть этот раздел сейчас и вернуться к нему позже.
14
 
 
15
 
Понимание номеров ревизий
16
 
-------------------------
17
 
 
18
 
All revisions in the mainline of a branch have a simple increasing
19
 
integer. (First commit gets 1, 10th commit gets 10, etc.) This makes them
20
 
fairly natural to use when you want to say "grab the 10th revision from my
21
 
branch", or "fixed in revision 3050".
22
 
 
23
 
For revisions which have been merged into a branch, a dotted notation is used
24
 
(e.g., 3112.1.5). Dotted revision numbers have three numbers [#]_. The first
25
 
number indicates what mainline revision change is derived from. The second
26
 
number is the branch counter. There can be many branches derived from the
27
 
same revision, so they all get a unique number. The third number is the
28
 
number of revisions since the branch started. For example, 3112.1.5 is the
29
 
first branch from revision 3112, the fifth revision on that branch.
30
 
 
31
 
.. [#] Versions prior to bzr 1.2 used a slightly different algorithm.
32
 
   Some nested branches would get extra numbers (such as 1.1.1.1.1)
33
 
   rather than the simpler 3-number system.
34
 
 
35
 
Hierarchical history is good
36
 
----------------------------
37
 
 
38
 
Imagine a project with multiple developers contributing changes where
39
 
many changes consist of a series of commits. To give a concrete example,
40
 
consider the case where:
41
 
 
42
 
 * The tip of the project's trunk is revision 100.
43
 
 * Mary makes 3 changes to deliver feature X.
44
 
 * Bill makes 4 changes to deliver feature Y.
45
 
 
46
 
If the developers are working in parallel and using a traditional
47
 
centralized VCS approach, the project history will most likely be linear
48
 
with Mary's changes and Bill's changes interleaved. It might look like this::
49
 
 
50
 
  107: Add documentation for Y
51
 
  106: Fix bug found in testing Y
52
 
  105: Fix bug found in testing X
53
 
  104: Add code for Y
54
 
  103: Add documentation for X
55
 
  102: Add code and tests for X
56
 
  101: Add tests for Y
57
 
  100: ...
58
 
 
59
 
Many teams use this approach because their tools make branching and merging
60
 
difficult. As a consequence, developers update from and commit to the trunk
61
 
frequently, minimizing integration pain by spreading it over every commit.
62
 
If you wish, you can use Bazaar exactly like this. Bazaar does offer other
63
 
ways though that you ought to consider.
64
 
 
65
 
An alternative approach encouraged by distributed VCS tools is to create
66
 
feature branches and to integrate those when they are ready. In this case,
67
 
Mary's feature branch would look like this::
68
 
 
69
 
  103: Fix bug found in testing X
70
 
  102: Add documentation for X
71
 
  101: Add code and tests for X
72
 
  100: ...
73
 
 
74
 
And Bill's would look like this::
75
 
 
76
 
  104: Add documentation for Y
77
 
  103: Fix bug found in testing Y
78
 
  102: Add code for Y
79
 
  101: Add tests for Y
80
 
  100: ...
81
 
 
82
 
If the features were independent and you wanted to keep linear history,
83
 
the changes could be pushed back into the trunk in batches. (Technically,
84
 
there are several ways of doing that but that's beyond the scope of
85
 
this discussion.) The resulting history might look like this::
86
 
 
87
 
  107: Fix bug found in testing X
88
 
  106: Add documentation for X
89
 
  105: Add code and tests for X
90
 
  104: Add documentation for Y
91
 
  103: Fix bug found in testing Y
92
 
  102: Add code for Y
93
 
  101: Add tests for Y
94
 
  100: ...
95
 
 
96
 
While this takes a bit more effort to achieve, it has some advantages over
97
 
having revisions randomly intermixed. Better still though, branches can
98
 
be merged together forming a non-linear history. The result might look
99
 
like this::
100
 
 
101
 
  102: Merge feature X
102
 
       100.2.3: Fix bug found in testing X
103
 
       100.2.2: Add documentation for X
104
 
       100.2.1: Add code and tests for X
105
 
  101: Merge feature Y
106
 
       100.1.4: Add documentation for Y
107
 
       100.1.3: Fix bug found in testing Y
108
 
       100.1.2: Add code for Y
109
 
       100.1.1: Add tests for Y
110
 
  100: ...
111
 
 
112
 
Or more likely this::
113
 
 
114
 
  102: Merge feature X
115
 
       100.2.3: Fix bug
116
 
       100.2.2: Add documentation
117
 
       100.2.1: Add code and tests
118
 
  101: Merge feature Y
119
 
       100.1.4: Add documentation
120
 
       100.1.3: Fix bug found in testing
121
 
       100.1.2: Add code
122
 
       100.1.1: Add tests
123
 
  100: ...
124
 
 
125
 
This is considered good for many reasons:
126
 
 
127
 
 * It makes it easier to understand the history of a project.
128
 
   Related changes are clustered together and clearly partitioned.
129
 
 
130
 
 * You can easily collapse history to see just the commits on the mainline
131
 
   of a branch. When viewing the trunk history like this, you only see
132
 
   high level commits (instead of a large number of commits uninteresting
133
 
   at this level).
134
 
 
135
 
 * If required, it makes backing out a feature much easier.
136
 
 
137
 
 * Continuous integration tools can be used to ensure that
138
 
   all tests still pass before committing a merge to the mainline.
139
 
   (In many cases, it isn't appropriate to trigger CI tools after
140
 
   every single commit as some tests will fail during development.
141
 
   In fact, adding the tests first - TDD style - will guarantee it!)
142
 
 
143
 
In summary, the important points are:
144
 
 
145
 
  *Organize your work using branches.*
146
 
 
147
 
  *Integrate changes using merge.*
148
 
 
149
 
  *Ordered revision numbers and hierarchy make history easier to follow.*
150
 
 
151
 
 
152
 
Each branch has its own view of history
153
 
---------------------------------------
154
 
 
155
 
As explained above, Bazaar makes the distinction between:
156
 
 
157
 
 * mainline revisions, i.e. ones you committed in your branch, and
158
 
 
159
 
 * merged revisions, i.e. ones added as ancestors by committing a merge.
160
 
 
161
 
Each branch effectively has its own view of history, i.e. different
162
 
branches can give the same revision a different "local" revision number.
163
 
Mainline revisions always get allocated single number revision numbers
164
 
while merged revisions always get allocated dotted revision numbers.
165
 
 
166
 
To extend the example above, here's what the revision history of
167
 
Mary's branch would look like had she decided to merge the project
168
 
trunk into her branch after completing her changes::
169
 
 
170
 
  104: Merge mainline
171
 
       100.2.1: Merge feature Y
172
 
       100.1.4: Add documentation
173
 
       100.1.3: Fix bug found in testing
174
 
       100.1.2: Add code
175
 
       100.1.1: Add tests
176
 
  103: Fix bug found in testing X
177
 
  102: Add documentation for X
178
 
  101: Add code and tests for X
179
 
  100: ...
180
 
 
181
 
Once again, it's easy for Mary to look at just *her* top level of history
182
 
to see the steps she has taken to develop this change. In this context,
183
 
merging the trunk (and resolving any conflicts caused by doing that) is
184
 
just one step as far as the history of this branch is concerned.
185
 
 
186
 
It's important to remember that Bazaar is not changing history here, nor
187
 
is it changing the global revision identifiers. You can always use the
188
 
latter if you really want to. In fact, you can use the branch specific
189
 
revision numbers when communicating *as long as* you provide the branch
190
 
URL as context. (In many Bazaar projects, developers imply the central
191
 
trunk branch if they exchange a revision number without a branch URL.)
192
 
 
193
 
Merges do not change revision numbers in a branch, though they do
194
 
allocate local revision numbers to newly merged revisions. The only time
195
 
Bazaar will change revision numbers in a branch is when you explicitly
196
 
ask it to mirror another branch.
197
 
 
198
 
Note: Revisions are numbered in a stable way: if two branches have
199
 
the same revision in their mainline, all revisions in the ancestry of that
200
 
revision will have the same revision numbers. For example, if Alice and Bob's
201
 
branches agree on revision 10, they will agree on all revisions before
202
 
that.
203
 
 
204
 
Резюме
205
 
------
206
 
 
207
 
Обычно, если вы следовали ранее полученным советам - организовать вашу работу
208
 
в ветках и использовать объединение для сотрудничества - вы обнаружите что
209
 
чаще всего Bazaar делает то что вы ожидаете.
210
 
 
211
 
В следующих главах, мы проверим различный способы использования Bazaar, начиная
212
 
с самого простого: использование Bazaar для личных проектов.
213
 
 
214
 
..
215
 
   vim: ft=rst tw=74 ai