← Back to branch summary

~svn/ubuntu/raring/subversion/ppa

« back to all changes in this revision

Viewing changes to doc/programmer/design/architecture.texi

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-12-05 01:26:14 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20051205012614-qom4xfypgtsqc2xq
Tags: 1.2.3dfsg1-3ubuntu1
Merge with the final Debian release of 1.2.3dfsg1-3, bringing in
fixes to the clean target, better documentation of the libdb4.3
upgrade and build fixes to work with swig1.3_1.3.27.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/programmer/design/architecture.texi
 
1
@node Architecture
 
2
@chapter Architecture
 
3
 
 
4
 
 
5
Subversion is conceptually divided into a number of separable layers.
 
6
 
 
7
Assuming that the programmatic interface of each layer is well-defined,
 
8
it is easy to customize the different parts of the system.  Contributors
 
9
can write new client apps, new network protocols, new server processes,
 
10
new server features, and new storage back-ends.
 
11
 
 
12
The following diagram illustrates the "layered" architecture, and where
 
13
each particular interface lies.
 
14
 
 
15
@example
 
16
@group
 
17
                    +--------------------+
 
18
                    | commandline or GUI |
 
19
                    |    client app      |
 
20
         +----------+--------------------+----------+ <=== Client interface
 
21
         |              Client Library              |
 
22
         |                                          |
 
23
         |        +----+                            |
 
24
         |        |    |                            |
 
25
 +-------+--------+    +--------------+--+----------+ <=== Network interface
 
26
 | Working Copy   |    |    Remote    |  | Local    |
 
27
 | Management lib |    | Repos Access |  | Repos    |
 
28
 +----------------+    +--------------+  | Access   |
 
29
                       |     neon     |  |          |
 
30
                       +--------------+  |          |
 
31
                          ^              |          |
 
32
                         /               |          |
 
33
                   DAV  /                |          |
 
34
                       /                 |          |
 
35
                      v                  |          |
 
36
              +---------+                |          |
 
37
              |         |                |          |
 
38
              | Apache  |                |          |
 
39
              |         |                |          |
 
40
              +---------+                |          |
 
41
              | mod_DAV |                |          |
 
42
            +-------------+              |          |
 
43
            | mod_DAV_SVN |              |          |
 
44
 +----------+-------------+--------------+----------+ <=== Filesystem interface
 
45
 |                                                  |
 
46
 |               Subversion Filesystem              |
 
47
 |                                                  |
 
48
 +--------------------------------------------------+
 
49
 
 
50
@end group
 
51
@end example
 
52
 
 
53
 
 
54
 
 
55
@menu
 
56
* Client Layer::              Client-side overview.
 
57
* Network Layer::             Network overview.
 
58
* Filesystem Layer::          Server-side overview.
 
59
@end menu
 
60
 
 
61
@c ------------------------------------------------------------------
 
62
@node Client Layer
 
63
@section Client Layer
 
64
 
 
65
The Subversion client, which may be either command-line or GUI, draws on
 
66
three libraries.
 
67
 
 
68
The working copy library, @file{libsvn_wc}, provides an API for
 
69
managing the client's working copy of a project.  This includes
 
70
operations like renaming or removal of files, patching files,
 
71
extracting local diffs, and routines for maintaining administrative
 
72
files in the @file{.svn/} directory.
 
73
 
 
74
The repository_access library, @file{libsvn_ra}, provides an API for
 
75
exchanging information with a Subversion repository.  This includes
 
76
the ability to read files, write new revisions of files, and ask the
 
77
repository to compare a working copy against its latest revision.
 
78
Note that there are two implementations of this interface: one
 
79
designed to talk to a repository over a network, and one designed to
 
80
work with a repository on local disk.  Any number of interface
 
81
implementations can exist.
 
82
 
 
83
The client library, @file{libsvn_client} provides general client
 
84
functions such as @code{update()} and @code{commit()}, which may
 
85
involve one or both of the other two client libraries.
 
86
@file{libsvn_client} should, in theory, provide an API that allows
 
87
anyone to write a Subversion client application.
 
88
 
 
89
For details, @xref{Client}.
 
90
 
 
91
@c ------------------------------------------------------------------
 
92
@node Network Layer
 
93
@section Network Layer
 
94
 
 
95
The network layer's job is to move the repository API requests over a
 
96
wire.
 
97
 
 
98
On the client side, a network library (@file{libneon}) translates
 
99
these requests into a set of HTTP WebDAV/DeltaV requests.  The
 
100
information is sent over TCP/IP to an Apache server.  Apache is used
 
101
for the following reasons:
 
102
 
 
103
@itemize @bullet
 
104
@item
 
105
it is time-tested and extremely stable;
 
106
@item
 
107
it has built-in load-balancing;
 
108
@item
 
109
it has built-in proxy and firewall support;
 
110
@item
 
111
it has authentication and encryption features;
 
112
@item
 
113
it allows client-side caching;
 
114
@item
 
115
it has an extensible module system
 
116
@end itemize
 
117
 
 
118
Our rationale is that any attempt to write a dedicated "Subversion
 
119
server" (with a "Subversion protocol") would inevitably end up
 
120
evolving towards Apache's already-existing feature set.  (However,
 
121
Subversion's layered architecture certainly doesn't @emph{prevent}
 
122
anyone from writing a totally new network access implementation.)
 
123
 
 
124
An Apache module (@file{mod_dav_svn}) translates the DAV requests into
 
125
API calls against a particular repository.
 
126
 
 
127
For details, @xref{Protocol}.
 
128
 
 
129
@c ------------------------------------------------------------------
 
130
@node Filesystem Layer
 
131
@section Filesystem Layer
 
132
 
 
133
When the requests reach a particular repository, they are interpreted
 
134
by the @dfn{Subversion Filesystem library}, @file{libsvn_fs}.  The
 
135
Subversion Filesystem is a custom Unix-like filesystem, with a twist:
 
136
writes are revisioned and atomic, and no data is ever deleted!  This
 
137
filesystem is currently implemented on top of a normal filesystem,
 
138
using Berkeley DB files.
 
139
 
 
140
For a more detailed explanation: @xref{Server}.