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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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".
I don't know how we got a year old version of mod_dav_syn but that is
apparently what is screwing up the http:// protocol.
> Each layer has a public API that can be used by other layers.
>
> Clients like 'svn' and TortoiseSVN primarily use the client library's API.
> The client library in turn calls into what is referred to as the "repository
> access" (RA) library, which selects a repository access implementation
> depending on the protocol used (http://, svn://, file://).
>
> But there are exceptions where clients bypass the RA layer.
> E.g. if you run TortoiseSVN and select the 'Create repository here'
> command (the equivalent to 'svnadmin create'), TortoiseSVN calls
> directly into the libsvn_repos API (the API for the big box labelled
> "Subversion Repository" in the figure) to create a repository
> on local disk.
>
> Getting back to your original question, the so-called "ra_local"
> repository access module (labelled "Local" in the figure) which
> implements file:// access to the repository calls directly into
> the libsvn_repos API to manupilate a repository on local disk.
> The 'svn' client is linked to the repository access library,
> and hence, indirectly, to the ra_local library and to libsvn_repos,
> to support file:// URLs. So you could say that 'svn' contains a copy
> of the same code that svnserve uses to access the repository. The
> copy is not embedded into the 'svn' binary itself, but is loaded
> from a library file (libsvn_repos.dll on Windows) when 'svn' (or
> svnserve) is started.
>
>> I read the wrong version of "The Book", the featured but obsolete
>> version. I shall download the "Nightly Build" version ASAP.
>>
> Unfortunately google keeps showing links to the 1.1 version of the book.
> This problem has existed for ages.
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.
Received on 2011-07-21 04:50:42 CEST