9
This document describes a possible workflow for using Bazaar_. That of
10
using Bazaar_, the distributed version control system, in a centralized
11
manner. Bazaar_ is designed to be very flexible and allows several
9
This document describes a possible workflow for using Breezy_. That of
10
using Breezy_, the distributed version control system, in a centralized
11
manner. Breezy_ is designed to be very flexible and allows several
12
12
different workflows, from fully decentralized to mostly centralized. The
13
13
workflow used here is meant to ease a new user into more advanced usage of
14
Bazaar_, and allow them to work in a mix of centralized and decentralized
14
Breezy_, and allow them to work in a mix of centralized and decentralized
17
17
In general, this document is meant for users coming from a background of
21
21
in sync. This workflow is also applicable to a single developer working
22
22
on several different machines.
24
.. _Bazaar: http://bazaar.canonical.com
24
.. _Breezy: http://bazaar.canonical.com
30
These are some reasonably simple steps to setup Bazaar_ so that it works
30
These are some reasonably simple steps to setup Breezy_ so that it works
43
% bzr whoami "John Doe <jdoe@organization.com>"
43
% brz whoami "John Doe <jdoe@organization.com>"
46
46
Setting up a local Repository
47
47
-----------------------------
49
Bazaar_ branches generally copy the history information around with them,
49
Breezy_ branches generally copy the history information around with them,
50
50
which is part of how you can work in a fully decentralized manner. As an
51
51
optimization, it is possible for related branches to combine their storage
52
52
needs so that you do not need to copy around all of this history
83
% bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
83
% brz init-repo --no-trees brz+ssh://centralhost/srv/brz/
85
85
You can think of this step as similar to setting up a new cvsroot, or
86
subversion repository. The ``--no-trees`` option tells bzr to not
86
subversion repository. The ``--no-trees`` option tells brz to not
87
87
populate the directory with a working tree. This is appropriate,
88
88
since no one will be making changes directly in the branches within
89
89
the central repository.
91
Here we're using a ``bzr+ssh`` URL, which means to use Bazaar's own
91
Here we're using a ``brz+ssh`` URL, which means to use Breezy's own
92
92
protocol on top of the SSH secure shell. See the Administrator Guide for
93
information about setting up a bzr+ssh server.
96
Migrating an existing project to Bazaar
93
information about setting up a brz+ssh server.
96
Migrating an existing project to Breezy
97
97
=======================================
99
99
Now that we have a repository, let's create a versioned project. Most of
100
100
the time, you will already have some code that you are working with,
101
that you now want to version using Bazaar_. If the code was originally
102
in source control, there are many ways to convert the project to Bazaar_
101
that you now want to version using Breezy_. If the code was originally
102
in source control, there are many ways to convert the project to Breezy_
103
103
without losing any history. However, this is outside the scope of this
104
104
document. See `Tracking Upstream`_ for some possibilities (section
105
105
"Converting and keeping history").
123
% bzr init bzr+ssh://centralhost/srv/bzr/sigil
123
% brz init brz+ssh://centralhost/srv/brz/sigil
125
125
This can be thought of as the "HEAD" branch in CVS terms, or as the "trunk"
126
126
in Subversion terms. We will call this the ``dev`` branch.
140
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
140
% brz checkout brz+ssh://centralhost/srv/brz/sigil dev
142
142
% cp -ar ~/sigil/* .
144
% bzr commit -m "Initial import of Sigil"
144
% brz commit -m "Initial import of Sigil"
147
147
In the previous section, we created an empty branch (the ``/sigil``
149
149
onto our workstation to add files from our existing project. There
150
150
are many ways to set up your working directory, but the steps above
151
151
make it easy to handle working with feature/bugfix branches. And one
152
of the strong points of Bazaar_ is how well it works with branches.
152
of the strong points of Breezy_ is how well it works with branches.
154
154
At this point, because you have a 'checkout' of the remote branch, any
155
155
commits you make in ``~/work/sigil/dev/`` will automatically be saved
166
166
To get a copy of the current development tree::
168
168
% cd ~/work/sigil
169
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
169
% brz checkout brz+ssh://centralhost/srv/brz/sigil dev
171
171
Now that two people both have a checkout of
172
``bzr+ssh://centralhost/srv/bzr/sigil``, there will be times when one of
172
``brz+ssh://centralhost/srv/brz/sigil``, there will be times when one of
173
173
the checkouts will be out of date with the current version.
174
At commit time, Bazaar_ will inform the user of this and prevent them from
175
committing. To get up to date, use ``bzr update`` to update the
174
At commit time, Breezy_ will inform the user of this and prevent them from
175
committing. To get up to date, use ``brz update`` to update the
176
176
tree with the remote changes. This may require resolving conflicts if the
177
177
same files have been modified.
190
190
integrate those back into the main branch, once they are stable. This is
191
191
one of the biggest changes from working with CVS/SVN. They both allow you
192
192
to work on separate branches, but their merging algorithms are fairly
193
weak, so it is difficult to keep things synchronized. Bazaar_ tracks
193
weak, so it is difficult to keep things synchronized. Breezy_ tracks
194
194
what has already been merged, and can even apply changes to files that
195
195
have been renamed.
207
207
% cd ~/work/sigil
208
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
209
bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
210
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
208
% brz branch brz+ssh://centralhost/srv/brz/sigil \
209
brz+ssh://centralhost/srv/brz/sigil/doodle-fixes
210
% brz checkout brz+ssh://centralhost/srv/brz/sigil/doodle-fixes doodle-fixes
211
211
% cd doodle-fixes
213
213
We now have a place to make any fixes we need to ``doodle``. And we would
225
225
.. [#cbranch] When using lots of independent branches, having to retype
226
226
the full URL all the time takes a lot of typing. We are looking into
227
227
various methods to help with this, such as branch aliases, etc. For
228
now, though, the bzrtools_ plugin provides the ``bzr cbranch`` command.
228
now, though, the brztools_ plugin provides the ``brz cbranch`` command.
229
229
Which is designed to take a base branch, create a new public branch,
230
230
and create a checkout of that branch, all with much less typing.
231
231
Configuring ``cbranch`` is outside the scope of this document, but the
245
245
to be merged into the main branch, simply do::
247
247
% cd ~/work/sigil/dev
248
% bzr merge ../doodle-fixes
248
% brz merge ../doodle-fixes
250
250
Now the changes are available in the ``dev`` branch, but they have not
251
251
been committed yet. This is the time when you want to review the final
252
252
changes, and double check the code to make sure it compiles cleanly and
253
passes the test suite. The commands ``bzr status`` and ``bzr diff`` are
253
passes the test suite. The commands ``brz status`` and ``brz diff`` are
254
254
good tools to use here. Also, this is the time to resolve any conflicts.
255
Bazaar_ will prevent you from committing until you have resolved these
255
Breezy_ will prevent you from committing until you have resolved these
256
256
conflicts. That way you don't accidentally commit the conflict markers.
257
The command ``bzr status`` will show the conflicts along with the other
258
changes, or you can use ``bzr conflicts`` to just list conflicts. Use
259
``bzr resolve file/name`` or ``bzr resolve --all`` once conflicts have
257
The command ``brz status`` will show the conflicts along with the other
258
changes, or you can use ``brz conflicts`` to just list conflicts. Use
259
``brz resolve file/name`` or ``brz resolve --all`` once conflicts have
260
260
been handled. [#resolve]_ If you have a conflict that is particularly
261
difficult to solve you may want to use the ``bzr remerge`` command. It
261
difficult to solve you may want to use the ``brz remerge`` command. It
262
262
will let you try different merge algorithms, as well as let you see the
263
263
original source lines (``--show-base``).
276
276
developer their own branch, and their own place to work in the central
277
277
location. This can be done with::
279
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
280
bzr+ssh://centralhost/srv/bzr/sigil/user-a
281
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
282
bzr+ssh://centralhost/srv/bzr/sigil/user-b
279
% brz branch brz+ssh://centralhost/srv/brz/sigil \
280
brz+ssh://centralhost/srv/brz/sigil/user-a
281
% brz branch brz+ssh://centralhost/srv/brz/sigil \
282
brz+ssh://centralhost/srv/brz/sigil/user-b
284
284
This gives each developer their own branch to work on. And, they can
285
285
easily create a new feature branch for themselves with just [#cbranch]_
288
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
289
bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
288
% brz branch brz+ssh://centralhost/srv/brz/sigil/user-a \
289
brz+ssh://centralhost/srv/brz/sigil/user-a/feature
290
290
% cd ~/work/sigil
291
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
291
% brz checkout brz+ssh://centralhost/srv/brz/sigil/user-a/feature myfeature
297
297
Shared Repository
298
298
-----------------
300
Bazaar_ has the concept of a "Shared Repository". This is similar to
300
Breezy_ has the concept of a "Shared Repository". This is similar to
301
301
the traditional concept of a repository in other VCSs like CVS and
302
302
Subversion. For example, in Subversion you have a remote repository,
303
303
which is where all of the history is stored, and locally you don't
306
306
branches. It *may* be shared between people, but standalone branches
307
307
can also be shared between people.
309
In Bazaar_ terms, a "Shared Repository" is a location where multiple
309
In Breezy_ terms, a "Shared Repository" is a location where multiple
310
310
branches can **share** their revision history information. In order to
311
311
support decentralized workflows, it is possible for every branch to
312
312
store its own revision history information. But this is often
added
removed
doc/en/tutorials/centralized_workflow.txt
