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
See this picture for a graphical representation of the various
layers Subversion is composed of:
I study the diagram. Starting at the top:
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.
- "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
- 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
- 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 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.
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.