← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/centralized_workflow.txt

  • Committer: John Arbash Meinel
  • Date: 2007-02-09 16:41:00 UTC
  • mto: This revision was merged to the branch mainline in revision 2294.
  • Revision ID: john@arbash-meinel.com-20070209164100-t9t1760kq6y5qgwn
Add get_cached_ascii for dealing with how cElementTree handles ascii strings

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/centralized_workflow.txt
1
 
=============================
2
 
Centralized Workflow Tutorial
3
 
=============================
 
1
====================
 
2
Centralized Workflow
 
3
====================
 
4
 
 
5
.. sectnum::
4
6
 
5
7
 
6
8
Overview
11
13
manner. Bazaar_ is designed to be very flexible and allows several
12
14
different workflows, from fully decentralized to mostly centralized.  The
13
15
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
 
16
Bazaar_, and allows them to work in a mix of centralized and decentralized
15
17
operations.
16
18
 
17
19
In general, this document is meant for users coming from a background of
23
25
 
24
26
.. _Bazaar: http://bazaar-vcs.org
25
27
 
 
28
.. contents::
 
29
 
26
30
 
27
31
Initial Setup
28
32
=============
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
 
52
56
needs so that you do not need to copy around all of this history
53
57
information whenever you create a new branch.
54
58
 
55
 
The best way to do this is to create a `Shared Repository`_. In
56
 
general, branches will share their storage if they exist in a
57
 
subdirectory of a `Shared Repository`_.  So let's set up a `Shared
58
 
Repository`_ in our home directory, thus all branches we create
59
 
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
 
63
storage.
60
64
 
61
65
::
62
66
 
83
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
87
 
populate the directory with a working tree.  This is appropriate,
88
 
since no one will be making changes directly in the branches within
89
 
the central repository.
90
 
 
91
 
 
92
 
Migrating an existing project to Bazaar
93
 
=======================================
 
90
subversion repository.
 
91
 
 
92
 
 
93
Versioning an existing project
 
94
==============================
94
95
 
95
96
Now that we have a repository, let's create a versioned project. Most of
96
97
the time, you will already have some code that you are working with,
102
103
 
103
104
.. _Tracking Upstream: http://bazaar-vcs.org/TrackingUpstream
104
105
 
105
 
..
 
106
.. 
106
107
   XXX: We really need a different document for discussing conversion of a
107
108
   project. Right now TrackingUpstream is the best we have, though.
108
109
 
111
112
----------------------------------------
112
113
 
113
114
So first, we want to create a branch in our remote Repository, where we
114
 
want to host the project.  Let's assume we have a project named
115
 
"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.
116
117
 
117
118
::
118
119
 
140
141
  % bzr commit -m "Initial import of Sigil"
141
142
 
142
143
 
143
 
In the previous section, we created an empty branch (the ``/sigil``
144
 
branch) on ``centralhost``, and then checkout out this empty branch
145
 
onto our workstation to add files from our existing project.  There
146
 
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
147
148
make it easy to handle working with feature/bugfix branches. And one
148
149
of the strong points of Bazaar_ is how well it works with branches.
149
150
 
150
151
At this point, because you have a 'checkout' of the remote branch, any
151
 
commits you make in ``~/work/sigil/dev/`` will automatically be saved
152
 
both locally, and on ``centralhost``.
 
152
commits you make in ``~/work/sigil/dev/`` will automatically be saved both locally,
 
153
and on ``centralhost``.
153
154
 
154
155
 
155
156
Developer N: Getting a working copy of the project
169
170
the checkouts will be out of date with the current version.
170
171
At commit time, Bazaar_ will inform the user of this and prevent them from
171
172
committing. To get up to date, use ``bzr update`` to update the
172
 
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
173
174
same files have been modified.
174
175
 
175
176
 
210
211
not interrupt people who are working on other parts of the code.  Because
211
212
we have a checkout, any commits made in the ``~/work/sigil/doodle-fixes/``
212
213
will also show up on ``centralhost``. [#nestedbranches]_ It is also
213
 
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
214
215
like they would have collaborated on the ``dev`` branch. [#cbranch]_
215
216
 
216
217
.. [#nestedbranches] It may look odd to have a branch in a subdirectory of
217
218
   another branch. This is just fine, and you can think of it as a
218
 
   hierarchical namespace where the nested branch is derived from the
 
219
   heirarchial namespace. Where the nested branch is derived from the
219
220
   outer branch.
220
221
 
221
222
.. [#cbranch] When using lots of independent branches, having to retype
225
226
   Which is designed to take a base branch, create a new public branch,
226
227
   and create a checkout of that branch, all with much less typing.
227
228
   Configuring ``cbranch`` is outside the scope of this document, but the
228
 
   final commands are similar to:
229
 
 
230
 
::
231
 
 
232
 
   % bzr cbranch dev my-feature-branch
233
 
 
234
 
.. _bzrtools: http://bazaar-vcs.org/BzrTools
 
229
   final commands look like ``bzr cbranch dev my-feature-branch``
 
230
 
 
231
.. _bzrtools: https://launchpad.net/products/bzrtools
235
232
 
236
233
 
237
234
Merging changes back
278
275
               sftp://centralhost/srv/bzr/sigil/user-b
279
276
 
280
277
This gives each developer their own branch to work on. And, they can
281
 
easily create a new feature branch for themselves with just [#cbranch]_
282
 
::
 
278
easily create a new feature branch for themselves with just[#cbranch]_::
283
279
 
284
280
  % bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
285
 
               sftp://centralhost/srv/bzr/sigil/user-a/feature
 
281
               sftp://centralhost/srv/bzr/sigil/user-a/feature 
286
282
  % cd ~/work/sigil
287
283
  % bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
288
284
 
293
289
Shared Repository
294
290
-----------------
295
291
 
296
 
Bazaar_ has the concept of a "Shared Repository". This is similar to
297
 
the traditional concept of a repository in other VCSs like CVS and
298
 
Subversion. For example, in Subversion you have a remote repository,
299
 
which is where all of the history is stored, and locally you don't
300
 
have any history information, only a checkout of the working tree
301
 
files. Note that "Shared" in this context means shared between
302
 
branches. It *may* be shared between people, but standalone branches
303
 
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.
304
299
 
305
300
In Bazaar_ terms, a "Shared Repository" is a location where multiple
306
 
branches can **share** their revision history information. In order to
307
 
support decentralized workflows, it is possible for every branch to
308
 
store its own revision history information. But this is often
309
 
inefficient, since related branches share history, and they might as
310
 
well share the storage as well.
311
 
 
312
 
 
313
 
..
 
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.
 
306
 
 
307
 
 
308
.. 
314
309
   vim: tw=74 ft=rst spell spelllang=en_us