Great...
On 07/21/2011 10:01 AM, Andy Levy wrote:
> 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.
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.
Received on 2011-07-21 06:37:38 CEST