On Mon, 15 May 2000, Paul D'Anna wrote:
> >From the server side, I can see that having Apache/mod_dav leverages
> building a separate server for subversion, allowing subversion to focus
> entirely on just repository functions and become a repository engine only
> (not a bad thing).
I completely agree. I have posted a couple times here, stating that I
believe the problem should be broken down into four parts:
1) client tools
2) network protocol (IMO: WebDAV)
3) server (IMO: Apache/mod_dav/subversion-backend-glue)
4) repository: Subversion
This gives us a nice divide-and-conquer approach. Even better: since
WebDAV is spec'd(*) and Apache/mod_dav is coded, then parts (2) and (3)
are greatly simplified for the Subversion effort.
The paper that Karl has been working on slots very nicely into (4). I
believe the initial client tool would operate exactly like today's "cvs"
tool, but speaks a different protocol out the back side (and *only* speaks
over the network; no multiple access mechanisms here)
(*) WebDAV core is RFC 2518. "DeltaV" is the versioning part and the
latest draft is available at http://www.webdav.org/deltav/. The draft
is the third in this series, but it follows on a prior series, so it
has gone thru many more iterations than it would appear. Note that
mod_dav already implements a plugin interface for "basic" versioning
as specified in the draft.
> What if any is the performance hit where the server would
> be used as a regular web server as well?
None. It is a web server. If requests come in for pages, they get served.
If a request comes in to fetch history information, it is served. If you
have separate servers, these requests must be served, too, so the total
processing is going to be the same in both cases.
I might even argue that Apache would provide benefits over a separate
server. Since you have a single executable, the working set could be
lower. Apache has been tuned, it is multi-threaded (in Apache 2.0), etc.
All of that would need to be redeveloped if a custom server were to be
built.
> Or is the assumption that a mod_dav
> enabled server is dedicated for subversion only.
I'm not assuming this, but an administrator could definitely set it up
this way. For example, they could run a server on a different port which
only served Subversion repositories.
IMO, the administrator would do something like this:
# set up my Subversion repository at /rep
<Location /rep>
DAV subversion
DAVParam svn-root /home/svnroot
Require group svnusers
</Location>
The above config says "use the subversion backend; set the 'svn-root'
parameter [consumed by the 'subversion' backend] to /home/svnroot; only
all users in the 'svnusers' group to access the /rep URL space."
> Would there ever be a need
> to have a non-Apache type of server for the repository and require a
> separate subversion protocol to access it?
Not in my view of the world :-)
The question is what requirement a separate protocol would be fulfilling.
If the WebDAV protocol cannot provide all the features that Subversion
needs, then the WebDAV design has not met its goal.
> >From the client side, I agree that supporting existing protocols would ease
> the conversion effort. But there also has to be back end conversions as well
> to import from other repositories into subversion. A least one from CVS to
> subversion to start with.
Agreed.
Note that I believe supporting the old protocol is *only* necessary
because we cannot provide replacement clients for all of the ones in use
today. For example, I presume we would provide a new set of command-line
clients for Unix-like operating systems. But what about WinCVS, MacCVS, or
Pharmacy replacements? What about the tools that have been written to
speak the CVS protocol?
Given those backward-compatibility "needs", I suggest a proxy. I do not
believe that the CVS protocol can meet our needs moving forward, but it
would be a disservice to ignore existing tools. Finally... I quoted
"needs" because while some people view it as a "need", I'm perfectly happy
to tell people "sorry: that tool does not work against this repository; go
get client FOO." In other words, I can see the need, but I'm not about to
write code to fulfill it :-)
> On your final thought: Existing clients that don't support WebDav needing
> some type of proxy to WebDav ... hmm .. I like it.
IMO, it is only there until people can upgrade. It is a crutch, and may
provide a subset of the complete CVS functionality. For example, it might
not support the "annotate" CVS operation or allow tagging to occur. A
proxy is also the easiest thing to write, rather than another protocol
server that operates against the Subversion repository. (for N reasons
that I won't detail unless somebody wants to argue the point :-))
But hey... it sounds like we're on the same wavelength :-)
Cheers,
-g
p.s. slightly off-topic, but I also have an app named "ViewCVS" that I
would gladly update/change/whatever to operate against Subversion
repositories. Info at http://www.lyra.org/viewcvs/. You can see it in
operation at http://www.apache.org/websrc/viewcvs.cgi/
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:04 2006