~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/config-specs.txt

• browse files at revision 1442.1.66
• compare with another revision
• download diff
• download tarball
• view history from revision 1442.1.66

• reverse the comparison (1442.1.66 to 1692.7.3)
• stop comparing with revision 1692.7.3

Show diffs side-by-side

added

removed

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

 

• Older »

Loggerhead is a web-based interface for Breezy
Version: 2.0.1