← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/shared_repository_layouts.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-11-30 05:43:20 UTC
  • mfrom: (3054.1.1 ianc-integration)
  • Revision ID: pqm@pqm.ubuntu.com-20071130054320-b4oer0rcbiy2ouzg
Bazaar User Guide for 1.0rc (Ian Clatworthy)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/shared_repository_layouts.txt
1
 
=======================
2
 
SharedRepositoryLayouts
3
 
=======================
4
 
 
5
 
.. sectnum::
 
1
Choosing a shared repository layout
 
2
===================================
6
3
 
7
4
Bazaar is designed to give you flexibility in how you layout branches inside a shared repository. 
8
5
This flexibility allows users to tailor Bazaar to their workflow,
14
11
and in most of the layouts this naming convention is preserved. Some would call this
15
12
"``mainline``" or "``dev``", and people from CVS often refer to this as "``HEAD``".
16
13
 
17
 
.. contents::
18
 
 
19
14
 
20
15
"SVN-Style" (``trunk/``, ``branches/``)
21
 
=======================================
 
16
---------------------------------------
22
17
 
23
18
Most people coming from SVN will be familiar with their "standard" project layout. 
24
19
Which is to layout the repository as::
130
125
 
131
126
 
132
127
Nested Style (``project/branch/sub-branch/``)
133
 
=============================================
 
128
---------------------------------------------
134
129
 
135
130
Another style with Bazaar, which is not generally possible in SVN
136
131
is to have branches nested within each-other.
202
197
 
203
198
 
204
199
Sorted by Status (``dev/``, ``merged/``, ``experimental/``)
205
 
===========================================================
 
200
-----------------------------------------------------------
206
201
 
207
202
One other way to break up branches is to sort them by their current status.
208
203
So you would end up with a layout something like::
249
244
 
250
245
 
251
246
Sorted by date/release/etc (``2006-06/``, ``2006-07/``, ``0.8/``, ``0.9``)
252
 
==========================================================================
 
247
--------------------------------------------------------------------------
253
248
 
254
249
Another method of allowing some scalability while also allowing the
255
250
browsing of "current" branches. Basically, this works on the assumption 
302
297
 
303
298
 
304
299
Simple developer naming (``project/joe/foo``, ``project/barry/bar``)
305
 
====================================================================
 
300
--------------------------------------------------------------------
306
301
 
307
302
Another possibly layout is to give each developer a directory, and then
308
303
have a single sub-directory for branches. Something like::
352
347
 
353
348
 
354
349
Summary
355
 
=======
 
350
-------
356
351
 
357
352
In the end, no single naming scheme will work for everyone. It depends a lot on
358
353
the number of developers, how often you create a new branch, what sort of