Arch as a replacement for CVS for OpenBSD?
A B
a replacement for CVS as the OpenBSD repository tree?
The feature comparison is impressive compared to CVS and Subversion:
http://www.regexps.com/src/src/arch/=FAQS/features.html
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
Martin Marconcini
> a replacement for CVS as the OpenBSD repository tree?
have you tried it?
Tom Lord
> Is anyone considering arch, http://www.regexps.com/#arch,
> a replacement for CVS as the OpenBSD repository tree?
I wanted to correct some errors and misleading statements:
Artur Grabowski writes of arch:
The feature comparison is made by the author.
And, in fact, contains corrections requested by the Subversion
developers. Yes, it is intended to focus on the strengths of arch --
not to be a broad survey of all systems available.
The documentation of the project is very confused and mixes slandering
of other projects with ramblings about open source philosophy and some
description about how to use it.
I hope other people won't take your word for that, but will check it
out for themselves. Several users have found the documentation to be
very effective, others find it confusing, personally, I think it's
somewhere in between. I don't think there's anything in it that fits
the inflammatory parts of your description.
It's not really clear to me how the repository works, but the
more I look at it the more I suspect that everyone must have
an own copy of the repository, making this a glorified variant
of rcs.
You are completely wrong which is pretty much what should be expected
if you are trying to dismiss a project that you yourself admit you
don't understand and are unwilling to learn about.
Arch is a distributed revision control system, meaning that projects
(branches etc.) can span repository boundaries. Any developer or
group _can_ have their own repository, which is very convenient in
many circumstances. No developer _must_ have their own repository.
This is not a replacement for cvs. A replacement would have a
small transitional cost. arch looks completly different from
all other revision handling systems I've seen. It's so
different that I won't even waste more time trying to
understand it.
It is very different from CVS. It takes a very different approach.
Consequently it is smaller and simpler, yet has very useful features
not found in CVS (such as atomic commits, support for renaming files,
high-level operations to ease the difficulty of merging branches, and
distributed repositories).
But don't even imagine that OpenBSD will switch the
revision handling system within a year or two. Something
like that must be done very carefully to a system that's
tested. If we'd want to do it at all.
At least we agree on something (the need for care and caution).
-t
Tobias Weingartner
>
> > The documentation of the project is very confused and mixes slandering
> > of other projects with ramblings about open source philosophy and some
> > description about how to use it.
>
> I hope other people won't take your word for that, but will check it
> out for themselves. Several users have found the documentation to be
> very effective, others find it confusing, personally, I think it's
> somewhere in between. I don't think there's anything in it that fits
> the inflammatory parts of your description.
I find that the documentation and TODO lists are largely diatribes
on how you'd like to accomplish some programming. Timelines for
when this could be done, given certain amounts of funding, etc.
I did not see any indication as to how complete and/or what is left
to do at the current time. In other words, short of downloading the
software, I have no idea how mature it is. Judging by the amount of
"marketing speak", it is not ready for prime-time.
> > It's not really clear to me how the repository works, but the
> > more I look at it the more I suspect that everyone must have
> > an own copy of the repository, making this a glorified variant
> > of rcs.
>
> You are completely wrong which is pretty much what should be expected
> if you are trying to dismiss a project that you yourself admit you
> don't understand and are unwilling to learn about.
Unwilling? Nope, he did peruse your web pages. I have as well.
The repository structure (on disk, etc) is not described well at
all. About the only thing I got out of that is that everything is
tree oriented. Branches, revisions, etc. There are problems with
this approach as well.
> Arch is a distributed revision control system, meaning that projects
> (branches etc.) can span repository boundaries. Any developer or
> group _can_ have their own repository, which is very convenient in
> many circumstances. No developer _must_ have their own repository.
Great. Something your web pages did not address. Do files (or
objects) within the repository have attributes associated with
them? IE: do the file permissions get saved somewhere? Can I add
custum attributes to each object? What are the costs associated
with doing large-scale diffs (300MB of source)? What are the
costs associated with doing large-scale "cvs annotate" style
operations?
> > This is not a replacement for cvs. A replacement would have a
> > small transitional cost. arch looks completly different from
> > all other revision handling systems I've seen. It's so
> > different that I won't even waste more time trying to
> > understand it.
>
> It is very different from CVS. It takes a very different approach.
> Consequently it is smaller and simpler, yet has very useful features
> not found in CVS (such as atomic commits, support for renaming files,
> high-level operations to ease the difficulty of merging branches, and
> distributed repositories).
What is that different approach? Where is the documentation that
explains this philosophy? It would help me in evaluating this
product in a manner usefull to me.
--Toby.
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Tom Lord
for prime-time.
Arch is indeed new: ready for "early adopters" not for people wanting
a glitch-free product. That fact is well documented in numerous
places and I have never assumed that the OpenBSD project as a whole
should or would be an "early adopter" at this stage.
[various complaints about the documentation]
I started to reply point-by-point to each question, but quickly came
to the conclusion that it might be more helpful to to write a brief
overview for programmers. That might make the existing documentation
easier to navigate and understand. Does the enclosed overview (at the
end of this message) help?
Here are answers to a few of the more interesting specific questions:
What are the costs associated with doing large-scale diffs (300MB of
source)?
In the current release, a few of us have measured 5-10x the cost of
"diff -r", depending on what's cached. We have a prototype for a new
version of `mkpatch' that benchmarks at 1-2x the cost of "diff -r".
What are the costs associated with doing large-scale "cvs annotate"
style operations?
See the note below about "revision libraries". You can do this sort
of operation very quickly. The built-in commands which perform such
operations are, admittedly, minimal, but revision libraries let you
get the same information more flexibly using ordinary shell tools.
What is that different approach? Where is the documentation
that explains this philosophy [the difference between arch and
CVS]?
I don't mean to be too flippant, but the documentation you're asking
for starts with P. J. Plauger's "Software Tools" and goes on from
there. arch is built out of simple tools that each do one thing well
and that are designed to be combined together. It combines those
tools in useful ways to yield a system of rich functionality that
requires very few lines of code to implement.
-t
A Hacker-Oriented Overview of Arch
* Foundations
The most central piece of (low level) functionality in arch is the
three commands: `mkpatch', `dopatch', and `inventory'. It is
easiest to understand the high level functionality of arch in terms
of those three commands.
Conceptually, `mkpatch' and `dopatch' are very similar to `diff -r'
and `patch'. The most important difference is that the arch
versions handle:
symbolic links
file permissions
renamed files and directories
files which `diff' thinks are binary files
`inventory' is used to identify which files in a tree are
significant, and to assign a logical identity to each file and
directory. The logical identity remains the same even if a file
is renamed and is the basis on which renames are detected.
* Sequences of Revisions
When you import a new tree to an arch repository, the essence of what
happens is that the tree is stored in the repository as a compressed
tar file. When you commit successive revisions of that tree, each
revision is stored as a compressed tar file containing the patch set
for that revision. (Also see below about "revision libraries".)
* Atomic Operations
Storing new revisions in an archive is an atomic operation. In
normal operation, locks are held transiently, only while the write
is being performed (similarly to CVS' "lock-less" operation).
Concurrent reads and writes do not interfere with one another.
* Revision Libraries
In addition to a repository of patch sets, arch is typically
configured to maintain a "revision library". A revision library is
a collection of revisions stored as complete copies of the source
tree, but with an important space optimization: unmodified files are
shared among these trees using hard links.
Many operations (such as checking out a new revision or computing
diffs between arbitrary revisions) use the revision library as a
performance optimization. In addition, programmers can use the
library directly with their favorite tools to explore various
revisions. (This is similar functionality to that offered by
ClearCase, but it is implemented in a portable way.)
* Tags
Any revision, instead of being a complete tar file of the entire
tree or a simple patch set, can be a "tag". Conceptually, a tag is
a symbolic link to some other revision. Tags are how branches are
implemented (the baseline revision of a branch is a tag of the
revision being branched from).
* Patch Logs
Each "project tree" (or, in CVS terms, "working directory") contains
meta-data that records what patch sets have been applied to that
tree. For example, when you merge one branch into another, the
merged-into branch gains patch logs for the changes from the
merged-from branch.
Arch contains some higher-level merge operations (e.g. star-merge,
replay) which use the patch logs to perform merges intelligently.
(For an example of why merging is a non-trivial problem, requiring
higher-level operations, see
http://www.regexps.com/src/docs.d/arch/html/star-topology.html)
Patch logs are also useful for data-mining about the history of a
tree. For example, they can be used to produce ChangeLog files.
* Name-spaces and Distributed Repositories
Every repository has a globally unique name. The name is location
independent: it remains the same for all mirrors of the repository
and if the repository is migrated.
Every revision in a repository has a unique name:
CATEGORY--BRANCH--VERSION--PATCH-LEVEL
Putting those two together, every revision has a globally unique
"fully qualified name" of the form:
REPOSITORY/CATEGORY--BRANCH--VERSION--PATCH-LEVEL
Tags use fully qualified names: thus you can form a branch from
one repository to another. Patch logs use fully qualified names,
thus the history of each project tree includes a record of all patch
sets merged into that tree, from any repository.
The effect of this is that, as far as arch is concerned, there is
just one global repository, stored in many distributed parts. There
is no centralized operation involved: anyone can create a new
repository, extending the global repository. Programmers can create
private repositories for day to day work. Loosely cooperating teams
can create branches of one anothers' projects.
Tobias Weingartner
>
> a glitch-free product. That fact is well documented in numerous
> places and I have never assumed that the OpenBSD project as a whole
> should or would be an "early adopter" at this stage.
I was not advocating its use for OpenBSD. I have also been looking
around for a different SCM tool. Arch I did not know about, so
I've had a quick (cursory) look at it.
> I started to reply point-by-point to each question, but quickly came
> to the conclusion that it might be more helpful to to write a brief
> overview for programmers. That might make the existing documentation
> easier to navigate and understand. Does the enclosed overview (at the
> end of this message) help?
Well, it does point out some limitations within your implementation
that I will try to point out. Thank you for the concise writeup.
> What is that different approach? Where is the documentation
> that explains this philosophy [the difference between arch and
> CVS]?
>
> I don't mean to be too flippant, but the documentation you're asking
> for starts with P. J. Plauger's "Software Tools" and goes on from
> there. arch is built out of simple tools that each do one thing well
> and that are designed to be combined together. It combines those
> tools in useful ways to yield a system of rich functionality that
> requires very few lines of code to implement.
That is the unix way. However, there has to be an underlying
cohesion to the whole mess. For example, unix uses the fork/exec
model of giving birth to a new process. That is fundamentally
different than what VMS and/or DOS give you. Both environments
have small blocks, but due to the nature of them, they are combined
differently, and have different end- functionality. IE: posix
compliance under VMS is actually quite hard, and it took
DEC/Compaq/HP/whatever-next quite some time to get something at
least somewhat useable (and reasonably portable) out there.
> * Foundations
>
> The most central piece of (low level) functionality in arch is the
> three commands: `mkpatch', `dopatch', and `inventory'. It is
> easiest to understand the high level functionality of arch in terms
> of those three commands.
In other words, you have 2 tools to manage change-sets (of sorts).
> Conceptually, `mkpatch' and `dopatch' are very similar to `diff -r'
> and `patch'. The most important difference is that the arch
> versions handle:
>
> symbolic links
> file permissions
> renamed files and directories
> files which `diff' thinks are binary files
This answers one of my questions already. You do not have a general
attribute system (or multiple file-streams) for each file. For
example, being able to largely interoperate between Mac and Unix
systems may require you to be able to store other additional
information about each file/directory. VMS may require file
structure information.
> `inventory' is used to identify which files in a tree are
> significant, and to assign a logical identity to each file and
> directory. The logical identity remains the same even if a file
> is renamed and is the basis on which renames are detected.
I gather that this identity will exist for eternity once it is in
existance? If so, how do you manage these identities? Is there
a cost associated with looking them up or managing them? What
operations gives rise to a new identity? Can you rename a branch
of a file, and have the trunk still be the original name?
I assume that directories are lists of such identities? If so,
can you have the equivelant of hard links (one file show up in two
directory objects)?
> * Sequences of Revisions
>
> When you import a new tree to an arch repository, the essence of what
> happens is that the tree is stored in the repository as a compressed
> tar file. When you commit successive revisions of that tree, each
> revision is stored as a compressed tar file containing the patch set
> for that revision. (Also see below about "revision libraries".)
In other words, I need to decompress/detar each revision (possibly quite
large) in order to construct a "diff" between 1.1 and 1.112 (that would
possibly be 112 decomp/detar)? Also, what ordering do you impose on the
construction of these diff sets? Are they in SCCS or RCS order? Some
other ordering?
> * Atomic Operations
>
> Storing new revisions in an archive is an atomic operation. In
> normal operation, locks are held transiently, only while the write
> is being performed (similarly to CVS' "lock-less" operation).
> Concurrent reads and writes do not interfere with one another.
This is a nice property.
> * Revision Libraries
>
> In addition to a repository of patch sets, arch is typically
> configured to maintain a "revision library". A revision library is
> a collection of revisions stored as complete copies of the source
> tree, but with an important space optimization: unmodified files are
> shared among these trees using hard links.
These are uncompressed/detarred versions of particular revisions of the
patch sets? IE: they exist wholesale within the repo? If so, how do
you handle moved/renamed files? Where do they exist? In both places?
Hardlink? Also, are the patch sets based on any of these revision
libraries? If so, how do you optimize speed/space wrt the number of
patch sets you need to apply to recover any one revision?
This functionality seems dangerously close to having a lock-step version
of the repo checked out. What I mean, is that you in some sense have a
global counter, which counts the "step" the repo is at. Each operation
increments the counter.
> Many operations (such as checking out a new revision or computing
> diffs between arbitrary revisions) use the revision library as a
> performance optimization. In addition, programmers can use the
> library directly with their favorite tools to explore various
> revisions. (This is similar functionality to that offered by
> ClearCase, but it is implemented in a portable way.)
How is this optimization implemented. What instrumentation do you use
and what policy does the repo use to store/delete things.
> * Tags
>
> Any revision, instead of being a complete tar file of the entire
> tree or a simple patch set, can be a "tag". Conceptually, a tag is
> a symbolic link to some other revision. Tags are how branches are
> implemented (the baseline revision of a branch is a tag of the
> revision being branched from).
Does this mean tags are global to the repo? This concept is very fuzy
to me. How do I compare this to the cvs tag/branch concept?
> * Patch Logs
>
> Each "project tree" (or, in CVS terms, "working directory") contains
> meta-data that records what patch sets have been applied to that
> tree. For example, when you merge one branch into another, the
> merged-into branch gains patch logs for the changes from the
> merged-from branch.
This can be very usefull. On "commit" does this information get saved
within the repository? If so, how?
> Arch contains some higher-level merge operations (e.g. star-merge,
> replay) which use the patch logs to perform merges intelligently.
> (For an example of why merging is a non-trivial problem, requiring
> higher-level operations, see
> http://www.regexps.com/src/docs.d/arch/html/star-topology.html)
Interesting way of looking at the problem. I've not read the complete
description yet, so can not comment on this.
> Patch logs are also useful for data-mining about the history of a
> tree. For example, they can be used to produce ChangeLog files.
Patch logs? Is this the meta-data you talked about before, or something
else?
> * Name-spaces and Distributed Repositories
>
> Every repository has a globally unique name. The name is location
> independent: it remains the same for all mirrors of the repository
> and if the repository is migrated.
How are they located? DNS entries? Config file?
> Every revision in a repository has a unique name:
>
> CATEGORY--BRANCH--VERSION--PATCH-LEVEL
Can you explain CATEGORY and how you deal with VERSION/PATCH-LEVEL?
IE: if something is in the repo, why should it have a PATCH-LEVEL?
> Tags use fully qualified names: thus you can form a branch from
> one repository to another. Patch logs use fully qualified names,
> thus the history of each project tree includes a record of all patch
> sets merged into that tree, from any repository.
Nice.
> The effect of this is that, as far as arch is concerned, there is
> just one global repository, stored in many distributed parts. There
> is no centralized operation involved: anyone can create a new
> repository, extending the global repository. Programmers can create
> private repositories for day to day work. Loosely cooperating teams
> can create branches of one anothers' projects.
How do you deal with people that wish to have their own repo? IE: they
explicitly do not with to be part of a branch or any other connection
with the official repo? How do you deal with patches from such places?
Do you have support for that, or is it handled much like cvs, except that
you maintian your own "vendor" branch?
--Toby.
Jonathan Walther
>places and I have never assumed that the OpenBSD project as a whole
>should or would be an "early adopter" at this stage.
You may want to try checking the Mozilla tree into arch. That thing is
huge! Purely for testing purposes.
You need a tool to convert a CVS repository to an ARCH one. Until then,
everyone who has invested their time in a CVS repository will be
reluctant to migrate.
>I started to reply point-by-point to each question, but quickly came
>to the conclusion that it might be more helpful to to write a brief
>overview for programmers. That might make the existing documentation
>easier to navigate and understand. Does the enclosed overview (at the
>end of this message) help?
One thing missing: please give us a MANIFEST; show us the layout of
the repository. For instance, those {arch} directories, where do they
go? What are all these files that start with the = sign? Where are
these compessed tar files stored? Where are the revision trees stored?
How do we access and manipulate them?
> What is that different approach? Where is the documentation
> that explains this philosophy [the difference between arch and
> CVS]?
>
>I don't mean to be too flippant, but the documentation you're asking
>for starts with P. J. Plauger's "Software Tools" and goes on from
Not all of us have access to Plaugers "Software Tools". But perhaps
you could just state you were following the "Unix Philosophy". But I
don't think that is what Art was getting at. For example, what does it
mean that branches can be distributed? It sounds nice, but how do you
manage it in real life? We need to see some example work patterns
illustrating all these advantages, all these things that CVS cannot do.
I for one wrapped my head around CVS only recently, after several years
of idly poking away at it.
Oh, one thing thats really missing: you depend on ftp. Most of us using
CVS prefer to use ssh as our transport. If you could see your way clear
to supporting that, even as the default method, it would be appreciated.
I don't want to run an ftp server on my machine just so people can
access my repositories. I shut off ftp for a reason, and only allow ssh
in.
> three commands: `mkpatch', `dopatch', and `inventory'. It is
> easiest to understand the high level functionality of arch in terms
> of those three commands.
How about checkins? I'm not clear if checkins are even needed with
arch. How do you do renames? Is there a mechanism to specify arbitrary
attributes for arbitrary files in the repository?
> Any revision, instead of being a complete tar file of the entire
> tree or a simple patch set, can be a "tag". Conceptually, a tag is
> a symbolic link to some other revision. Tags are how branches are
> implemented (the baseline revision of a branch is a tag of the
> revision being branched from).
This isn't clear at all. Can a tag point to a revision elsewhere in the
global repository? How is a tag stored? I know what a CVS tag is; how
is this different? Please illustrate with the appropriate ls -l
commands.
> Every repository has a globally unique name. The name is location
> independent: it remains the same for all mirrors of the repository
> and if the repository is migrated.
You didn't mention that the "globally unique name" for repositories so
far has been peoples email addresses. What can and cannot be a
repository name? Are some characters permitted and not others?
> REPOSITORY/CATEGORY--BRANCH--VERSION--PATCH-LEVEL
Please give a couple of examples? You work at a high level of
abstraction. For me at least, I need things to be made concrete to
understand them.
> repository, extending the global repository. Programmers can create
> private repositories for day to day work. Loosely cooperating teams
> can create branches of one anothers' projects.
Illustrations. How would a programmer make this private repository? Is
it the same as a cvs checkout? How is it different?
Jonathan
--
Geek House Productions, Ltd.
Providing Unix & Internet Contracting and Consulting,
QA Testing, Technical Documentation, Systems Design & Implementation,
General Programming, E-commerce, Web & Mail Services since 1998
Phone: 604-435-1205
Email: d...@reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC V5R2W2
[demime 0.98d removed an attachment of type application/pgp-signature]
Tom Lord
it is a "misc" list, I'll answer weingart's questions for now. You
can also ask questions on the "arch-users" or "arch-dev" list
(@regexps.com). I've not answered some of the questions that I'm sure
are clear from the documentation.
> [various reasons why arch is not ideal for VMS or Mac]
Right. arch is for Posix environments.
> `inventory' is used to identify which files in a tree are
> significant, and to assign a logical identity to each file and
> directory. The logical identity remains the same even if a file
> is renamed and is the basis on which renames are detected.
I gather that this identity will exist for eternity once it is
in existance? If so, how do you manage these identities?
See http://www.regexps.com/src/docs.d/arch/html/inventory.html
Is there a cost associated with looking them up or managing
them?
Very little. The documentation should make that clear.
What operations gives rise to a new identity?
Using mechanism (1) or (3), just creating a new file does it. If you
use mechanism (2), then you also need to run `larch add FILENAME'.
Can you rename a branch of a file, and have the trunk still be
the original name?
Yes. In fact, I do this all the time. I have a generic package
("module" in CVS-speak) for the top-level directory of all software I
distribute. I have branches or each distribution. On those
branches, once, a while back, I stored revisions that modify the
generic top-level package by removing some files and rearranging other
ones. To make a new release, I just `larch star-merge' the generic
package with the release-specific branches and all of those deletions
and rearrangements happen automatically. For example, the generic top
level has:
docs.d/
docs.d/arch/
docs.d/arch/html/
...
docs.d/hackerlab/
docs.d/systas/
The distribution branch for arch renames "docs.d/arch" to "docs" and
deletes the other files. I never have to do that by hand any more: it
happens automatically during merging.
You can even have a situation where two branches use different names
for the same file. When you merge back and forth between these
branches, each branch still has its own name for the file, but the
changes are made to the right file in each case.
I assume that directories are lists of such identities?
Not quite. A directory is just a directory. It has both a location
name (a relative path) and a logical name (that determines its role
when making or applying patch sets). When the mkpatch/dopatch process
tries to decide where a file or directory belongs, it looks at the
logical id of the directory that contains it.
If so, can you have the equivelant of hard links (one file
show up in two directory objects)?
Not at the moment. Is that a feature you need for some reason? If
so, can you describe how you use it?
In other words, I need to decompress/detar each revision (possibly
quite large) in order to construct a "diff" between 1.1 and 1.112
(that would possibly be 112 decomp/detar)?
No. Revision libraries let you construct a diff with no such
overhead in the general case. In special cases (e.g. diffs between a
project tree and its immediate ancestor) other caching mechanisms
eliminate that overhead.
> * Revision Libraries
>
> In addition to a repository of patch sets, arch is typically
> configured to maintain a "revision library". A revision library is
> a collection of revisions stored as complete copies of the source
> tree, but with an important space optimization: unmodified files are
> shared among these trees using hard links.
These are uncompressed/detarred versions of particular revisions of the
patch sets? IE: they exist wholesale within the repo? If so, how do
you handle moved/renamed files? Where do they exist? In both places?
Hardlink? Also, are the patch sets based on any of these revision
libraries? If so, how do you optimize speed/space wrt the number of
patch sets you need to apply to recover any one revision?
A revision library is uncompressed/detarred versions of the entire
trees of revisions -- except that files that are common between
revisions (even if renamed) are shared via hard-links.
Patch sets are, by default, constructed from revision libraries and
project trees. This is about as low-overhead as you can possibly get.
As a fallback, when there is no revision library or the necessary
revisions are missing from the library, they are constructed the slow
way (by first building the ORIG or MOD tree from the patch sets.).
This functionality seems dangerously close to having a lock-step version
of the repo checked out. What I mean, is that you in some sense have a
global counter, which counts the "step" the repo is at. Each operation
increments the counter.
Nope. There is a counter ("patch level") for each development line
("branch" in CVS-speak, "version" in arch-speak). However, all those
counters are independent of one another.
> * Tags
>
> Any revision, instead of being a complete tar file of the entire
> tree or a simple patch set, can be a "tag". Conceptually, a tag is
> a symbolic link to some other revision. Tags are how branches are
> implemented (the baseline revision of a branch is a tag of the
> revision being branched from).
Does this mean tags are global to the repo? This concept is
very fuzy to me. How do I compare this to the cvs tag/branch
concept?
A tag is just a record in the repository that means "to get this
revision, X (the tag revision), go and get that other revision, Y (the
tagged revision) and add the patch log entry for X."
In CVS, every file in a tree must be tagged independently of the
others. In arch, you tag everything at once.
> * Patch Logs
This can be very usefull. On "commit" does this information get saved
within the repository? If so, how?
Each (whole-tree) revision is stored in its own directory. One of the
(plain-text, roughly RFC822-format) files in that directory is the log
entry for that revision.
> Every repository has a globally unique name. The name is location
> independent: it remains the same for all mirrors of the repository
> and if the repository is migrated.
How are they located? DNS entries? Config file?
A config file maps the logical name of the repository to a URL or
local path. "ftp:" method URLs are currently supported, and there are
some patches pending for an SSH-based transport.
How do you deal with people that wish to have their own repo? IE: they
explicitly do not with to be part of a branch or any other connection
with the official repo? How do you deal with patches from such places?
Do you have support for that, or is it handled much like cvs, except that
you maintian your own "vendor" branch?
I'm not sure what you're asking. There are no special problems with
that situation.
-t