Great...
On 07/21/2011 10:01 AM, Andy Levy wrote:
On Wed, Jul 20, 2011 at 22:42, Andy Canfield<andy.canfi...@pimco.mobi> wrote:
Thank you very much.
On 07/20/2011 05:44 PM, Stefan Sperling wrote:
On Wed, Jul 20, 2011 at 05:22:57PM +0700, Andy Canfield wrote:
One quirk is that if he URL specifies direct access, e.t. svn ...
file:///var/svn/RepoName, then where is the code which actually
manipulates the contents of the /var/svn/RepoName directory? It must
be hidden in svn itself, or perhaps svn forks a call to something
like svnserve as a subtask to get the manipulations done for it,
since there is no server program already running on the server
computer.
See this picture for a graphical representation of the various
layers Subversion is composed of:
http://svnbook.red-bean.com/nightly/en/svn.intro.whatis.html#svn.intro.architecture
I study the diagram. Starting at the top:
"commandline client app" - since you don't put a name on it, apparently this
is a program that I write. Same with "GUI client apps" - since there is no
name it must be a program that I write.
No. It's just a placeholder for any of the various clients that are
available. Instead of listing all of the apps and having to maintain
that list as they appear and disappear. I have 4 clients installed on
my workstation - there wouldn't be any value in listing them all in
that diagram, because any one of them could up and disappear tomorrow.
Each of these access a "Client Library". This Client LIbrary access the
Working Copy Management Library. Somebody, presumably the WCML, access my
working copy of the repository.
As a user, you never see the client library. It's built into (or
linked by) your client.
But as a system administrator, for installing packages from Ubuntu, I
often see library names etc. Also as a programmer I often run into
libraries that no longer exist, library version problems, etc. But I
know what you mean. As a user of subversion I should not see them
assuming that my system administrator has taken care of things.
Then the Client Library access the "Repository Access". This I have to
assume is a PROTOCOL, not a PROGRAM. There are three; DAV, SVN, and Local.
The access layer is part of the program code. Again, as a user, you
only care which ones you have available (to make sure you can access a
repository using the method(s) provided by the administrator), not
*how* they're implemented.
At this point things DAV and SVN go through the Internet or any other TCP/IP
network.
DAV goes through Apache and from here to mod_dav and through that to
mod_dav_syn. The "mod_dav_fs" is not mentioned at all.
mod_dav is a standard Apache module which implements the WebDAV
protocol. mod_dav_svn is an Apache module developed by/for the
Subversion team which specifically implements Subversion using WebDAV
(which is why it's in a box *inside* mod_dav's box).
There is no mod_fs because ra_local doesn't utilize Apache as a server.
But there is a file named "mod_dav_fs.so" on both the intended server
and on my notebook trial server. If WebDAV is not specific to Subversion
then maybe some other package / feature uses mod_dav_fs.so. Ahah! Google
to the rescue. From http://httpd.apache.org/docs/2.0/mod/mod_dav_fs.html
I learn that mod_dav_fs.so "acts as a support module for mod_dav and
provides access to resources located in the server's file system."
At this point we see the first blast. My copyof mod_dav_syn.so is
timestamped about a year BEFORE the build date on Apache, which is within
one day of the timestamp on mod_dav.sl. Whereas it is not unusual for a
timestamp to be made later (e.g. via cp without -p), it is almost impossible
for mod_dav_syn to have been build for this Apache and then the timestamp
moved earlier. This must be why DAV access is crashing.
It's not 100% definite, but it's an extremely likely root cause.
Alternatively, the SVN protocol will go to the svnserve program.
Below the mod_dav_syn layer and the svnserve layer and the repository local
layer is the "Subversion Repository". Significantly, this is diagrammed as
data, not code. So mod_dav_syn must contain the code to manipulate the
repository, and svnserve must also contain the code to manipulate the
repository, and the Client Library (because of Local access) must contain
the code to manipulate the repository.
Below the "Subversion Repository" component is either "Berkeley DB" or
"FSFS". I have already decided to use "FSFS" since I can look at it as it's
sitting on the disk and therefore it is more conceptually transparent.
FSFS doesn't expose the files directly. It's still a database of
sorts, just not a BDB database. You still need a Subversion client to
access the files.
But I don't need a Subversion client to see the files, to read the
files, and therefore to learn how things are stored. I'm the kind of guy
who has looked at the directory & file structure created by MySQL for
it's databases. It becomes possible to see the low-level implementation
in case that answers a question about the high-level interface. Hey,
that's why I use Linux and not the Microsoft Black Box System.
Significantly, the "svn" PROGRAM never appears on this diagram. Because the
svn program is supposed to accept any of the three types of URL (http://
svn:// or file://) the svn program must be a "commandline client app".
The "svn" program is one of many clients. As noted above, the clients
are not described by name because an architecture diagram is not the
appropriate place to list all clients.
I understand. There are many "commandline client app"s. But only certain
ones are shipped as a part of the Subversion package.
I was not confused by Google. I was confused by the web page
http://svnbook.red-bean.com/. On that page there are two versions of the
book. The first is labelled "For Subversion 1.5", the other is labelled
"Nightly Build (for Subversion 1.7)". I read the first one, under the
traditional assumption that anything named "Nightly Build" is alpha and not
to be relied upon in a production environment. I was wrong; I will read the
second.
The concepts described in the book change much less frequently than
the code. A significant portion of the "nightly" book applies to older
versions - but of course there are changes to cover new/modified
functionality, and general edits& reorganization. There was no final
version of the book for 1.6.
I suggest that the "Nightly Build" version be relabelled "Current", and
put first.
Thank you very much.
