/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/centralized_workflow.txt

  • Committer: Brad Crittenden
  • Date: 2007-02-27 22:14:14 UTC
  • mfrom: (2293.2.2 bzr.dev)
  • mto: This revision was merged to the branch mainline in revision 2311.
  • Revision ID: bac@canonical.com-20070227221414-du51ihnpkdu59geo
Merge from my LP branch

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
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
 
90
subversion repository.  The {{{--no-trees}}} option tells bzr to not
 
91
populate the directory with a working tree.  This is appropriate since
 
92
no one will be making changes directly in the branches within the
 
93
central repository.
 
94
 
 
95
 
 
96
Placing an existing project into Bazaar
93
97
=======================================
94
98
 
95
99
Now that we have a repository, let's create a versioned project. Most of
96
100
the time, you will already have some code that you are working with,
97
101
that you now want to version using Bazaar_. If the code was originally
98
 
in source control, there are many ways to convert the project to Bazaar_
 
102
in source control there are many ways to convert the project to Bazaar_
99
103
without losing any history. However, this is outside the scope of this
100
104
document. See `Tracking Upstream`_ for some possibilities (section
101
105
"Converting and keeping history").
102
106
 
103
107
.. _Tracking Upstream: http://bazaar-vcs.org/TrackingUpstream
104
108
 
105
 
..
 
109
.. 
106
110
   XXX: We really need a different document for discussing conversion of a
107
111
   project. Right now TrackingUpstream is the best we have, though.
108
112
 
140
144
  % bzr commit -m "Initial import of Sigil"
141
145
 
142
146
 
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
 
147
In the previous section, we created an empty branch (the ``/sigil`` branch)
 
148
on ``centralhost``, and then checkout out this empty branch onto our
 
149
workstation to add files from our existing project.
 
150
There are many ways to setup your working directory, but the steps above
147
151
make it easy to handle working with feature/bugfix branches. And one
148
152
of the strong points of Bazaar_ is how well it works with branches.
149
153
 
150
154
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``.
 
155
commits you make in ``~/work/sigil/dev/`` will automatically be saved both locally,
 
156
and on ``centralhost``.
153
157
 
154
158
 
155
159
Developer N: Getting a working copy of the project
231
235
 
232
236
   % bzr cbranch dev my-feature-branch
233
237
 
234
 
.. _bzrtools: http://bazaar-vcs.org/BzrTools
 
238
.. _bzrtools: https://launchpad.net/products/bzrtools
235
239
 
236
240
 
237
241
Merging changes back
282
286
::
283
287
 
284
288
  % bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
285
 
               sftp://centralhost/srv/bzr/sigil/user-a/feature
 
289
               sftp://centralhost/srv/bzr/sigil/user-a/feature 
286
290
  % cd ~/work/sigil
287
291
  % bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
288
292
 
294
298
-----------------
295
299
 
296
300
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.
 
301
the concept of a repository in other RCSs. For example, in Subversion
 
302
you have a remote repository, which is where all of the history is
 
303
stored, and locally you don't have any history information, only a
 
304
checkout of the working tree files. Note that "Shared" in this context
 
305
means shared between branches. It *may* be shared between people, but
 
306
standalone branches can also be shared between people.
304
307
 
305
308
In Bazaar_ terms, a "Shared Repository" is a location where multiple
306
309
branches can **share** their revision history information. In order to
307
310
support decentralized workflows, it is possible for every branch to
308
 
store its own revision history information. But this is often
 
311
maintain its own revision history information. But this is often
309
312
inefficient, since related branches share history, and they might as
310
313
well share the storage as well.
311
314
 
312
315
 
313
 
..
 
316
.. 
314
317
   vim: tw=74 ft=rst spell spelllang=en_us