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
19
19
In general, this document is meant for users coming from a background of
56
56
needs so that you do not need to copy around all of this history
57
57
information whenever you create a new branch.
59
The best way to do this is to create a `Shared Repository`_. In general,
60
branches will share their storage if they exist in a subdirectory of a
61
`Shared Repository`_. So let's setup a `Shared Repository`_ in our home
62
directory, thus all branches we create underneath will share their history
59
The best way to do this is to create a `Shared Repository`_. In
60
general, branches will share their storage if they exist in a
61
subdirectory of a `Shared Repository`_. So let's set up a `Shared
62
Repository`_ in our home directory, thus all branches we create
63
underneath will share their history storage.
87
87
% bzr init-repo --no-trees sftp://centralhost/srv/bzr/
89
89
You can think of this step as similar to setting up a new cvsroot, or
90
subversion repository.
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,
92
since no one will be making changes directly in the branches within
93
the central repository.
96
Migrating an existing project to Bazaar
97
=======================================
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,
112
115
----------------------------------------
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.
141
144
% bzr commit -m "Initial import of Sigil"
144
In the example above, we created an empty branch (the ``/sigil`` branch)
145
on ``centralhost``, and then checkout out this empty branch onto our
146
workstation to add files from our existing project.
147
There are many ways to setup your working directory, but the steps above
147
In the previous section, we created an empty branch (the ``/sigil``
148
branch) on ``centralhost``, and then checkout out this empty branch
149
onto our workstation to add files from our existing project. There
150
are many ways to set up your working directory, but the steps above
148
151
make it easy to handle working with feature/bugfix branches. And one
149
152
of the strong points of Bazaar_ is how well it works with branches.
151
154
At this point, because you have a 'checkout' of the remote branch, any
152
commits you make in ``~/work/sigil/dev/`` will automatically be saved both locally,
153
and on ``centralhost``.
155
commits you make in ``~/work/sigil/dev/`` will automatically be saved
156
both locally, and on ``centralhost``.
156
159
Developer N: Getting a working copy of the project
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.
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]_
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
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:
236
% bzr cbranch dev my-feature-branch
231
238
.. _bzrtools: https://launchpad.net/products/bzrtools
275
282
sftp://centralhost/srv/bzr/sigil/user-b
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]_
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
-----------------
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 traditional concept of a repository in other RCSs like CVS and
302
Subversion. For example, in Subversion you have a remote repository,
303
which is where all of the history is stored, and locally you don't
304
have any history information, only a checkout of the working tree
305
files. Note that "Shared" in this context means shared between
306
branches. It *may* be shared between people, but standalone branches
307
can also be shared between people.
300
309
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.
310
branches can **share** their revision history information. In order to
311
support decentralized workflows, it is possible for every branch to
312
store its own revision history information. But this is often
313
inefficient, since related branches share history, and they might as
314
well share the storage as well.
added
removed
doc/centralized_workflow.txt
