← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/centralized_workflow.txt

  • Committer: joe blow
  • Date: 2007-02-27 21:24:38 UTC
  • mto: (2293.1.5 bzr.dev)
  • mto: This revision was merged to the branch mainline in revision 2311.
  • Revision ID: joe@blow.com-20070227212438-ndpq6lsmn9ahroz5
Updated documents for grammer, spelling, and clarity.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/centralized_workflow.txt
13
13
manner. Bazaar_ is designed to be very flexible and allows several
14
14
different workflows, from fully decentralized to mostly centralized.  The
15
15
workflow used here is meant to ease a new user into more advanced usage of
16
 
Bazaar_, and allows them to work in a mix of centralized and decentralized
 
16
Bazaar_, and allow them to work in a mix of centralized and decentralized
17
17
operations.
18
18
 
19
19
In general, this document is meant for users coming from a background of
87
87
  % bzr init-repo --no-trees sftp://centralhost/srv/bzr/
88
88
 
89
89
You can think of this step as similar to setting up a new cvsroot, or
90
 
subversion repository.
91
 
 
92
 
 
93
 
Versioning an existing project
94
 
==============================
 
90
subversion repository.  The {{{--no-trees}}} option tells bzr to not
 
91
populate the directory with a working tree.  This is appropriate since
 
92
no one will be making changes directly in the branches within the
 
93
central repository.
 
94
 
 
95
 
 
96
Placing an existing project into Bazaar
 
97
=======================================
95
98
 
96
99
Now that we have a repository, let's create a versioned project. Most of
97
100
the time, you will already have some code that you are working with,
98
101
that you now want to version using Bazaar_. If the code was originally
99
 
in source control, there are many ways to convert the project to Bazaar_
 
102
in source control there are many ways to convert the project to Bazaar_
100
103
without losing any history. However, this is outside the scope of this
101
104
document. See `Tracking Upstream`_ for some possibilities (section
102
105
"Converting and keeping history").
112
115
----------------------------------------
113
116
 
114
117
So first, we want to create a branch in our remote Repository, where we
115
 
will want to host the project.  Let's assume we have a project named
116
 
"sigil" that we want to start versioning.
 
118
want to host the project.  Let's assume we have a project named
 
119
"sigil" that we want to put under version control.
117
120
 
118
121
::
119
122
 
141
144
  % bzr commit -m "Initial import of Sigil"
142
145
 
143
146
 
144
 
In the example above, we created an empty branch (the ``/sigil`` branch)
 
147
In the previous section, we created an empty branch (the ``/sigil`` branch)
145
148
on ``centralhost``, and then checkout out this empty branch onto our
146
149
workstation to add files from our existing project.
147
150
There are many ways to setup your working directory, but the steps above
170
173
the checkouts will be out of date with the current version.
171
174
At commit time, Bazaar_ will inform the user of this and prevent them from
172
175
committing. To get up to date, use ``bzr update`` to update the
173
 
tree with the remote changes. This may require resolving conflicts, if the
 
176
tree with the remote changes. This may require resolving conflicts if the
174
177
same files have been modified.
175
178
 
176
179
 
211
214
not interrupt people who are working on other parts of the code.  Because
212
215
we have a checkout, any commits made in the ``~/work/sigil/doodle-fixes/``
213
216
will also show up on ``centralhost``. [#nestedbranches]_ It is also
214
 
possible to have 2 developers collaborate on one of these branches, just
 
217
possible to have two developers collaborate on one of these branches, just
215
218
like they would have collaborated on the ``dev`` branch. [#cbranch]_
216
219
 
217
220
.. [#nestedbranches] It may look odd to have a branch in a subdirectory of
218
221
   another branch. This is just fine, and you can think of it as a
219
 
   heirarchial namespace. Where the nested branch is derived from the
 
222
   hierarchical namespace where the nested branch is derived from the
220
223
   outer branch.
221
224
 
222
225
.. [#cbranch] When using lots of independent branches, having to retype
226
229
   Which is designed to take a base branch, create a new public branch,
227
230
   and create a checkout of that branch, all with much less typing.
228
231
   Configuring ``cbranch`` is outside the scope of this document, but the
229
 
   final commands look like ``bzr cbranch dev my-feature-branch``
 
232
   final commands are similar to:
 
233
 
 
234
::
 
235
 
 
236
   % bzr cbranch dev my-feature-branch
230
237
 
231
238
.. _bzrtools: https://launchpad.net/products/bzrtools
232
239
 
275
282
               sftp://centralhost/srv/bzr/sigil/user-b
276
283
 
277
284
This gives each developer their own branch to work on. And, they can
278
 
easily create a new feature branch for themselves with just[#cbranch]_::
 
285
easily create a new feature branch for themselves with just [#cbranch]_
 
286
::
279
287
 
280
288
  % bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
281
289
               sftp://centralhost/srv/bzr/sigil/user-a/feature 
289
297
Shared Repository
290
298
-----------------
291
299
 
292
 
Bazaar_ has the concept of a "Shared Repository". This is similar to the
293
 
concept of other RCS's repository. Such as in Subversion, where you have a
294
 
remote repository, which is where all of the history is stored, and
295
 
locally you don't have any history information, only a checkout of the
296
 
working tree files. Note that "Shared" in this context means shared
297
 
between branches. It *may* be shared between people, but standalone
298
 
branches can also be shared between people.
 
300
Bazaar_ has the concept of a "Shared Repository". This is similar to
 
301
the concept of a repository in other RCSs. For example, in Subversion
 
302
you have a remote repository, which is where all of the history is
 
303
stored, and locally you don't have any history information, only a
 
304
checkout of the working tree files. Note that "Shared" in this context
 
305
means shared between branches. It *may* be shared between people, but
 
306
standalone branches can also be shared between people.
299
307
 
300
308
In Bazaar_ terms, a "Shared Repository" is a location where multiple
301
 
branches can **share** their revision history information. Because Bazaar_
302
 
wants to support decentralized workflows, it is possible for every branch
303
 
to maintain its own revision history information. But this is often
304
 
inefficient, since related branches share history, and they might as well
305
 
share the storage as well.
 
309
branches can **share** their revision history information. In order to
 
310
support decentralized workflows, it is possible for every branch to
 
311
maintain its own revision history information. But this is often
 
312
inefficient, since related branches share history, and they might as
 
313
well share the storage as well.
306
314
 
307
315
 
308
316
..