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
|
// file : bpkg/rep-add.cli
// copyright : Copyright (c) 2014-2017 Code Synthesis Ltd
// license : MIT; see accompanying LICENSE file
include <libbpkg/manifest.hxx>;
include <bpkg/configuration.cli>;
"\section=1"
"\name=bpkg-rep-add"
"\summary=add repository to configuration"
namespace bpkg
{
{
"<options> <rep-loc> <tag> <branch> <commit-id>",
"\h|SYNOPSIS|
\c{\b{bpkg rep-add}|\b{add} [<options>] <rep-loc>...}
\h|DESCRIPTION|
The \cb{rep-add} command adds the specified package repositories to the
configuration. The repository location <rep-loc> is a URL or a directory
path. If a repository with the same canonical name already exists in the
configuration, then its location is replaced with the specified.
Note that this command doesn't fetch the list of available packages for
the newly added repository. For that, use the \l{bpkg-rep-fetch(1)}
command, normally, after adding all the repositories you wish to use.
Currently two types of repositories are supported: \cb{pkg} and \cb{git}.
Normally the repository type can be automatically guessed by examining
its URL (for example, the presence of the \cb{.git} extension) or, in
case of a local repository, its content (for example, the presence of the
\cb{.git/} subdirectory). Without any identifying information the
\cb{pkg} type is assumed unless explicitly specified with the \cb{--type}
option.
A \cb{pkg} repository is \i{archive}-based. That is, it contains a
collection of various packages/versions as archive files. For more
information on the structure of \cb{pkg} repositories refer to the
\l{bpkg \cb{bpkg} manual}.
A \cb{git} repository is \i{version control}-based. That is, it normally
contains multiple versions of the same package (but can also contain
several packages in the same repository).
Theoretically, a \cb{git} repository may contain as many package versions
as there are commits. Practically, however, we are normally only
interested in a small subset of them while fetching and processing the
necessary information for all of them could be prohibitively expensive.
As a result, a \cb{git} repository URL must include the fragment
component that restricts the set of versions to consider as available.
While in the future it will be possible to specify multiple available
versions, currently the fragment must identify a single version using one
of the following forms:
\
#<tag>
#<branch>
#<commit-id>
#<branch>@<commit-id>
\
In the last form <branch> is only used to minimize the amount of data to
fetch. If specified, then the commit must belong to its history.
No abbreviated commit ids are supported and <commit-id> must be the
complete, 40-characters SHA1 string. A 40-characters fragment that
consists of only hexadecimal digits is assumed to be a commit id and a
branch/tag otherwise. In an unlikely case this produces an incorrect
result, the last form with omitted <commit-id> can be used.
Below are some examples of \cb{git} repository URLs:
\
https://example.com/foo.git#v1.2.3
https://example.com/foo.git#master
https://example.com/foo.git#48fba3625d65941bb85a39061bcf795d4949c778
https://example.com/foo.git#bar@48fba3625d65941bb85a39061bcf795d4949c778
https://example.com/foo.git#deadbeefdeadbeefdeadbeefdeadbeefdeadbeef@
\
A \cb{git} repository is expected to contain either the \cb{manifest} or
\cb{packages.manifest} file in the root directory of the repository. If
it only contains \cb{manifest}, then it is assumed to be a single-package
repository with the \cb{manifest} file being its package manifest.
Otherwise the \cb{packages.manifest} file should list the available
packages as described in \l{bpkg#manifest-package-list-git Package List
Manifest for \cb{git} Repositories}.
A \cb{git} repository may also contain the \cb{repositories.manifest}
file in the root directory of the repository. This file can be used to
describe the repository itself as well as specify its prerequisite and
complement repositories. See \l{bpkg#manifest-repository-list Repository
List Manifest} for details on the format and semantics of this file.
Supported git protocols are \cb{git://}, \cb{http://}, and \cb{https://}
for remote repositories and \cb{file://} for local repositories. While
\cb{bpkg} tries to minimize the amount of information (history) fetched,
it is not always possible for some protocols and/or server
configurations, as discussed next.
A \cb{git} repository accessible via \cb{http(s)://} can use either
\i{dumb} or \i{smart} protocol (refer to the \cb{git} documentation for
details). The dumb protocol provides only limited support for fetch
minimization and if this protocol is used, then \cb{bpkg} has no choice
but to download a substantial amount of history.
The smart protocol allows fetching of minimal history for tags and
branches. Whether this is also possible for (all) commit ids depends on
whether the server is configured to allow fetching unadvertised commits.
For details, refer to the \cb{uploadpack.allowReachableSHA1InWant} and
\cb{uploadpack.allowAnySHA1InWant} \cb{git} configuration values.
The \cb{git://} protocol is similar to smart \cb{http://} in that it
supports fetching minimal history for tags and branches and may or may
not support this for commit ids depending on the server configuration.
Note, however, that unlike for \cb{http(s)://}, for this protocol
\cb{bpkg} does not try to sense if fetching unadvertised commits is
allowed and always assumes that it is not.
Based on this information, to achieve optimal results the recommended
protocol for remote repositories is smart \cb{https://}. Additionally, if
you are planning to refer to commit ids, then also consider configuring
the server to allow fetching unadvertised commits.
The \cb{file://} protocol has the same fetch minimization support as
\cb{git://} and is therefore treated the same."
}
class rep_add_options: configuration_options
{
"\h|REP-ADD OPTIONS|"
repository_type --type
{
"<type>",
"Specify the repository type with valid values being \cb{pkg} and
\cb{git}."
}
};
}
|