← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/config-specs.txt

  • Committer: Martin Pool
  • Date: 2009-07-10 07:14:02 UTC
  • mto: (4525.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 4526.
  • Revision ID: mbp@sourcefrog.net-20090710071402-dga5lhvdup5jeere
Rename remaining *_implementations tests

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/config-specs.txt
1
 
************
2
 
Config specs
3
 
************
4
 
 
5
 
A *config spec* is a set of instructions for assembling a source tree
6
 
from separately maintained branches.  This is like CVS's "modules"
7
 
format.  Config specs are very commonly used in Clearcase, and the
8
 
main way of getting a new checkout.
9
 
 
10
 
Scenarios:
11
 
 
12
 
 * One module is shared by several projects, and it needs to be
13
 
   present in a subdirectory of their trees to build.
14
 
 
15
 
 * There are different commit or stability rules for different parts
16
 
   of a tree.
17
 
 
18
 
The simplest form is just a specification of branch sources, and where
19
 
they should be assembled into the tree.  Example::
20
 
 
21
 
  .              http://foo.net/fooapp
22
 
  ./libbaz       http://foo.net/libbaz
23
 
 
24
 
Normally the entire branch will be placed at this point, but sometimes
25
 
subdirectory should be selected.  Selecting just a single file rather
26
 
than subdirectory might be problematic because we wouldn't have
27
 
anywhere to put the control files.
28
 
 
29
 
Each branch will have a .bzr directory at the top level.  Changes on
30
 
each branch can be pushed back independently.
31
 
 
32
 
The tool needs to support (and be tested with) nested checkouts.
33
 
Commands should normally only apply to a single tree, but there might
34
 
be an option to descend into nested trees.
35
 
 
36
 
One very important use case is a naive user checking out a tree that
37
 
happens to use a configspec.  This is transparent in cvs, but not at
38
 
all so in Arch.
39
 
 
40
 
The ``svn:externals`` mechanism in Subversion works like this.
41
 
 
42
 
One interesting idea from Aaron is that all branches should be like
43
 
this: the latest-patch pointer can be generalized to in fact name
44
 
several patches that should be assembled in subdirectories.  A
45
 
simplest branch names just one, assembled to the base directory.  You
46
 
might want to specify the parent branches for each one as well....
47