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 allow them to work in a mix of centralized and decentralized
16
Bazaar_, and allows 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
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.
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
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. 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
=======================================
90
subversion repository.
93
Versioning an existing project
94
==============================
99
96
Now that we have a repository, let's create a versioned project. Most of
100
97
the time, you will already have some code that you are working with,
115
112
----------------------------------------
117
114
So first, we want to create a branch in our remote Repository, where we
118
want to host the project. Let's assume we have a project named
119
"sigil" that we want to put under version control.
115
will want to host the project. Let's assume we have a project named
116
"sigil" that we want to start versioning.
144
141
% bzr commit -m "Initial import of Sigil"
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
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
151
148
make it easy to handle working with feature/bugfix branches. And one
152
149
of the strong points of Bazaar_ is how well it works with branches.
154
151
At this point, because you have a 'checkout' of the remote branch, any
155
commits you make in ``~/work/sigil/dev/`` will automatically be saved
156
both locally, and on ``centralhost``.
152
commits you make in ``~/work/sigil/dev/`` will automatically be saved both locally,
153
and on ``centralhost``.
159
156
Developer N: Getting a working copy of the project
173
170
the checkouts will be out of date with the current version.
174
171
At commit time, Bazaar_ will inform the user of this and prevent them from
175
172
committing. To get up to date, use ``bzr update`` to update the
176
tree with the remote changes. This may require resolving conflicts if the
173
tree with the remote changes. This may require resolving conflicts, if the
177
174
same files have been modified.
214
211
not interrupt people who are working on other parts of the code. Because
215
212
we have a checkout, any commits made in the ``~/work/sigil/doodle-fixes/``
216
213
will also show up on ``centralhost``. [#nestedbranches]_ It is also
217
possible to have two developers collaborate on one of these branches, just
214
possible to have 2 developers collaborate on one of these branches, just
218
215
like they would have collaborated on the ``dev`` branch. [#cbranch]_
220
217
.. [#nestedbranches] It may look odd to have a branch in a subdirectory of
221
218
another branch. This is just fine, and you can think of it as a
222
hierarchical namespace where the nested branch is derived from the
219
heirarchial namespace. Where the nested branch is derived from the
225
222
.. [#cbranch] When using lots of independent branches, having to retype
229
226
Which is designed to take a base branch, create a new public branch,
230
227
and create a checkout of that branch, all with much less typing.
231
228
Configuring ``cbranch`` is outside the scope of this document, but the
232
final commands are similar to:
236
% bzr cbranch dev my-feature-branch
238
.. _bzrtools: http://bazaar-vcs.org/BzrTools
229
final commands look like ``bzr cbranch dev my-feature-branch``
231
.. _bzrtools: https://launchpad.net/products/bzrtools
241
234
Merging changes back
282
275
sftp://centralhost/srv/bzr/sigil/user-b
284
277
This gives each developer their own branch to work on. And, they can
285
easily create a new feature branch for themselves with just [#cbranch]_
278
easily create a new feature branch for themselves with just[#cbranch]_::
288
280
% bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
289
281
sftp://centralhost/srv/bzr/sigil/user-a/feature
297
289
Shared Repository
298
290
-----------------
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.
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.
309
300
In Bazaar_ terms, a "Shared Repository" is a location where multiple
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.
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.
added
removed
doc/centralized_workflow.txt
