1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
<html>
<head>
<title>Multi-tree Projects and Configuration Management</title>
</head>
<body>
<a name="Multi-tree_Projects_and_Configuration_Management"></a>
<a href="http://www.regexps.com">The Hackerlab at <code>regexps.com</code></a>
<h2 align=center>Multi-tree Projects and Configuration Management</h2>
<small>
<b>up: </b><a href="arch.html#arch">arch</a></br>
</small>
<br>
<p>You can define <em>
<a name="index-pt:0"></a>
meta-projects
</em>
which are combinations of individual
projects that are separately tracked by <code>arch</code>
. This allows you to
divide a large project into smaller, more managable pieces, each of
which can develop independently of the others, and each of which can
be a part of more than one meta-project.
</p><p>This is accomplished by writing <em>
<a name="index-pt:1"></a>
config specs
</em>
, which define the
contents of the meta-project and how they should be arranged in a
source tree.
</p><p>For example, <code>arch</code>
itself is a meta-project. The source tree
contains:
</p><pre>
dists/
dists/src/
dists/src/arch/
dists/src/file-utils/
dists/src/ftp-utils/
dists/src/hackerlab/
dists/src/shell-utils/
</pre>
<p>Each of those directories is the root of a project tree (contains a
subdirectory named <em>
<a name="index-pt:2"></a>
{arch}
</em>
).
</p><p>The top most directory, <code>dists</code>
also contains a subdirectory named
<code>configs</code>
. In that subdirectory are the metaproject configuration
files. For example:
</p><pre>
dists/
dists/configs/
dists/configs/regexps.com/ # Tom's configuration files
dists/configs/regexps.com/devo.arch
dists/configs/regexps.com/release-template.arch
</pre>
<p>Here are the contents of <code>devo.arch</code>
:
</p><pre>
#
# Check out an arch distribution from the devo branches.
# Latest revisions.
#
</pre>
<pre>
./src lord@regexps.com--2002/package-framework--devo
./src/arch lord@regexps.com--2002/arch--devo
./src/file-utils lord@regexps.com--2002/file-utils--devo
./src/ftp-utils lord@regexps.com--2002/ftp-utils--devo
./src/hackerlab lord@regexps.com--2002/hackerlab--devo
./src/shell-utils lord@regexps.com--2002/shell-utils--devo
./src/text-utils lord@regexps.com--2002/text-utils--devo
</pre>
<p>Each (non-blank, non-comment) line in that file has the format:
</p><pre>
LOCATION CONTENTS
</pre>
<p>which means, to create the meta-project, get the revision indicated by
<code>CONTENTS</code>
and install it at <code>LOCATION</code>
. The <code>CONTENTS</code>
field can be
a branch (meaning, get the latest revision of the latest version on
that branch), a version (meaning get the latest revision in that
version), or a revision name (meaning get that revision, exactly).
</p><p>To check out an entire <code>arch</code>
tree, I first check out <code>dists</code>
from
<code>devo</code>
, then use <code>build-config</code>
:
</p><pre>
% larch get dists--devo dists
[....]
</pre>
<pre>
% cd dists
</pre>
<pre>
% larch build-config regexps.com/dists.devo
[....]
</pre>
<p>Once you have a meta-project tree, some other useful commands are:
</p><pre>
update-config : update a multi-project tree
replay-config : replay a multi-project tree
</pre>
<p>Those commands recursively <code>update</code>
or <code>replay</code>
the sub-trees in a
meta-project.
</p><p>One more configuration management command:
</p><pre>
% larch record-config GENERAL-CONFIG SPECIFIC-CONFIG
</pre>
<p>That reads a config file, the <code>GENERAL-CONFIG</code>
. It examines the
project tree to see what revisions are actually installed at each of
the <code>LOCATIONs</code>
. Then it writes a new config file, the
<code>SPECIFIC-CONFIG</code>
that has <code>CONTENTS</code>
which specify those <code>REVISIONS</code>
precisely. This is useful, for example, for recording the specific
revisions you are about to turn into a distribution.
</p>
<small><i>arch: The arch Revision Control System
</i></small><br>
<a href="http://www.regexps.com">The Hackerlab at <code>regexps.com</code></a>
</body>
|
