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
|
Building this software is the usual ./configure && make.
You may run it uninstalled if you wish.
Using it is a little more complex, but if you have been
instructed to use it to get the source for some other
piece of software, it's very easy:
./cm build -d <where you want the software checked out> config-file
i.e.
./cm build -d ~/src/project1 project1.txt
updating all the source in that project? <TODO>
Creating or altering a config? Read on.
A config is a plain text file describing the structure of a directory
tree in terms of revision control projects. Creating one is as simple
as identifying the source for each revision control project that makes
up the tree, and recording that source along with the relative position
in a text file.
File format:
# indicates the beginning of a comment. comments go to end of line.
./ indicates the beginning of a project path, and must be followed by the
path, whitespace, and a project url.
other whitespace is ignore, and a line not beginning with ./ or # is
a syntax error.
project paths:
* must be relative.
* must be unique within a config. (duplicates are silently ignored).
* may be emtpy (that is "./") to indicate a root path.
normal paths: are passed to the appropriate sub commands with the leading ./
stripped.
root paths: are not used in tla build unless the -d option has been passed to
cm, in which case they are passed as "." to the sub commands. Root paths are
always used by cm cat.
url schemes:
a url scheme identified the particular type of Revision Control System (RCS)
being used to access the project's source. Each scheme has it's own syntax.
The scheme is identified by the leading "<scheme>://" portion of the url.
A missing scheme is treated specially, as a backwards compatability issue.
At this point, rfc 1738 en and de coding is not performed on the urls in the
config file.
The schemes:
Missing scheme: Treated as an arch category + optional branch, version and
revision.
arch:// As per the missing scheme, with an extension: supply @<url>
after the arch details and if the arch repository is not registered, cm will
register it with tla on the fly. Any support arch location systax is supported
as long as it doesn't contain spaces.
pserver:// identifies a CVS pserver repository. See sample-config.txt for
details.
ext:// identifies a CVS ext repository. Your CVS_RSH must be set
appropriately before calling cm. Yes, this means all ext urls must share the
same CVS_RSH. See sample-config.txt for CVS url examples.
http:// identifies a location based repository.
ftp:// identifies a location based repository. A location based
repository is one where someone has simply stashed an archived copy of their
source tree. I.e. foo.tar.bz2. At time of writing, the following permutations
where supported: <foo>.tar[.(bz2|gz)]. location based repositories cannot be
updated per se: only extracted via cm build. The archive should contain one
and only one top level directory. That will be renamed to the requested path
at build time.
svn:// a Subversion repository available over the insecure "svn"
protocol.
svn+ssh:// a Subversion repository available over the "svn" protocol
tunneled over SSH.
svn+http:// a Subversion repository available over HTTP/WebDAV.
svn+https:// a Subversion repository available over HTTP/WebDAV over
TLS/SSL.
svn+file:// a Subversion repository available on a local filesystem.
|
