← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/tutorials/centralized_workflow.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2008-09-03 22:30:56 UTC
  • mfrom: (3644.2.13 index_builder_cleanup)
  • Revision ID: pqm@pqm.ubuntu.com-20080903223056-b108iytb38xkznci
(jam) Streamline BTreeBuilder.add_node et al to make btree creation
        faster.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/tutorials/centralized_workflow.txt
1
 
=============================
2
 
Centralized Workflow Tutorial
3
 
=============================
 
1
====================
 
2
Centralized Workflow
 
3
====================
 
4
 
 
5
.. sectnum::
4
6
 
5
7
 
6
8
Overview
21
23
in sync.  This workflow is also applicable to a single developer working
22
24
on several different machines.
23
25
 
24
 
.. _Bazaar: http://bazaar.canonical.com
 
26
.. _Bazaar: http://bazaar-vcs.org
 
27
 
 
28
.. contents::
25
29
 
26
30
 
27
31
Initial Setup
38
42
be accurate or unique, it will be used in log messages and
39
43
annotations, so it is better to have something real.
40
44
 
41
 
::
 
45
::  
42
46
 
43
47
   % bzr whoami "John Doe <jdoe@organization.com>"
44
48
 
80
84
 
81
85
::
82
86
 
83
 
  % bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
 
87
  % bzr init-repo --no-trees sftp://centralhost/srv/bzr/
84
88
 
85
89
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
 
90
subversion repository.  The {{{--no-trees}}} option tells bzr to not
87
91
populate the directory with a working tree.  This is appropriate,
88
92
since no one will be making changes directly in the branches within
89
93
the central repository.
90
94
 
91
 
Here we're using a ``bzr+ssh`` URL, which means to use Bazaar's own
92
 
protocol on top of the SSH secure shell.  See the Administrator Guide for
93
 
information about setting up a bzr+ssh server.  
94
 
 
95
95
 
96
96
Migrating an existing project to Bazaar
97
97
=======================================
104
104
document. See `Tracking Upstream`_ for some possibilities (section
105
105
"Converting and keeping history").
106
106
 
107
 
.. _Tracking Upstream: http://wiki.bazaar.canonical.com/TrackingUpstream
 
107
.. _Tracking Upstream: http://bazaar-vcs.org/TrackingUpstream
108
108
 
109
 
..
 
109
.. 
110
110
   XXX: We really need a different document for discussing conversion of a
111
111
   project. Right now TrackingUpstream is the best we have, though.
112
112
 
120
120
 
121
121
::
122
122
 
123
 
  % bzr init bzr+ssh://centralhost/srv/bzr/sigil
 
123
  % bzr init sftp://centralhost/srv/bzr/sigil
124
124
 
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.
137
137
  % cd work
138
138
  % mkdir sigil
139
139
  % cd sigil
140
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
 
140
  % bzr checkout sftp://centralhost/srv/bzr/sigil dev
141
141
  % cd dev
142
142
  % cp -ar ~/sigil/* .
143
143
  % bzr add
166
166
To get a copy of the current development tree::
167
167
 
168
168
  % cd ~/work/sigil
169
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
 
169
  % bzr checkout sftp://centralhost/srv/bzr/sigil dev
170
170
 
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
``sftp://centralhost/srv/bzr/sigil``, there will be times when one of
173
173
the checkouts will be out of date with the current version.
174
174
At commit time, Bazaar_ will inform the user of this and prevent them from
175
175
committing. To get up to date, use ``bzr update`` to update the
205
205
::
206
206
 
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
  % bzr branch sftp://centralhost/srv/bzr/sigil \
 
209
               sftp://centralhost/srv/bzr/sigil/doodle-fixes
 
210
  % bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
211
211
  % cd doodle-fixes
212
212
 
213
213
We now have a place to make any fixes we need to ``doodle``. And we would
235
235
 
236
236
   % bzr cbranch dev my-feature-branch
237
237
 
238
 
.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
 
238
.. _bzrtools: http://bazaar-vcs.org/BzrTools
239
239
 
240
240
 
241
241
Merging changes back
276
276
developer their own branch, and their own place to work in the central
277
277
location. This can be done with::
278
278
 
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
  % bzr branch sftp://centralhost/srv/bzr/sigil \
 
280
               sftp://centralhost/srv/bzr/sigil/user-a
 
281
  % bzr branch sftp://centralhost/srv/bzr/sigil \
 
282
               sftp://centralhost/srv/bzr/sigil/user-b
283
283
 
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]_
286
286
::
287
287
 
288
 
  % bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
289
 
               bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
 
288
  % bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
 
289
               sftp://centralhost/srv/bzr/sigil/user-a/feature 
290
290
  % cd ~/work/sigil
291
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
 
291
  % bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
292
292
 
293
293
 
294
294
Glossary
298
298
-----------------
299
299
 
300
300
Bazaar_ has the concept of a "Shared Repository". This is similar to
301
 
the traditional concept of a repository in other VCSs like CVS and
 
301
the traditional concept of a repository in other RCSs 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
304
304
have any history information, only a checkout of the working tree
314
314
well share the storage as well.
315
315
 
316
316
 
317
 
..
 
317
.. 
318
318
   vim: tw=74 ft=rst spell spelllang=en_us