← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/centralized_workflow.txt

  • Committer: Brad Crittenden
  • Date: 2007-03-02 12:40:45 UTC
  • mto: This revision was merged to the branch mainline in revision 2311.
  • Revision ID: bac@canonical.com-20070302124045-3a9o45va231z0w0a
post review changes

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/centralized_workflow.txt
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.
58
58
 
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.
 
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.
64
64
 
65
65
::
66
66
 
88
88
 
89
89
You can think of this step as similar to setting up a new cvsroot, or
90
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
 
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.
 
94
 
 
95
 
 
96
Migrating an existing project to Bazaar
97
97
=======================================
98
98
 
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
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_
 
102
in source control, there are many ways to convert the project to Bazaar_
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").
144
144
  % bzr commit -m "Initial import of Sigil"
145
145
 
146
146
 
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
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
151
151
make it easy to handle working with feature/bugfix branches. And one
152
152
of the strong points of Bazaar_ is how well it works with branches.
153
153
 
154
154
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 both locally,
156
 
and on ``centralhost``.
 
155
commits you make in ``~/work/sigil/dev/`` will automatically be saved
 
156
both locally, and on ``centralhost``.
157
157
 
158
158
 
159
159
Developer N: Getting a working copy of the project
298
298
-----------------
299
299
 
300
300
Bazaar_ has the concept of a "Shared Repository". This is similar to
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.
 
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.
307
308
 
308
309
In Bazaar_ terms, a "Shared Repository" is a location where multiple
309
310
branches can **share** their revision history information. In order to
310
311
support decentralized workflows, it is possible for every branch to
311
 
maintain its own revision history information. But this is often
 
312
store its own revision history information. But this is often
312
313
inefficient, since related branches share history, and they might as
313
314
well share the storage as well.
314
315