On Wed, Jul 20, 2011 at 22:42, Andy Canfield <andy.canfield_at_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.
> 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.
> 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.
> 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 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.
Received on 2011-07-21 05:03:14 CEST