On Mon, Feb 26, 2001 at 06:37:50PM -0800, Bruce Atherton wrote:
> Eric's message concerning the lack of discussion around architecture has
> prompted me to post concerning some ideas that I think are important for
> Subversion.
Well, that's because most of the architecture is somewhat settled, and we're
now executing on it :-) Some of the discussion has also happened a bit in
person or on the phone. But I think most of it is kind of a "group gestalt"
and we're just coding it now.
>...
> a) Adding a CVS proxy
[ note: CVS client talking to SVN server ]
>...
> CVS clients have finally become somewhat ubiquitous. Most IDEs provide at
> least some support for CVS built in, some of them quite sophisticated. We
> are finally at the point that SCC has been at for years. Yes, the client
> library will simplify porting new clients into new environments, but it
> still must be admitted that this process will take some time.
Agreed. However, I don't think anybody has volunteered to write this yet
(nor have we listed it as a 1.0 requirement). But as GregH wrote: we
wouldn't refuse it either :-)
>...
> So how to create this Proxy? I can think of several ways:
>
> - Existing CVS source code could be linked into the new libraries (ugh!)
Considering the CVS codebase fragility, this may be a non-starter. I'd hate
to imagine CVS pserver built against libsvn_fs.
> - Apache 2.0 is supposed to have better support for implementing new
> protocols, so in theory we could write a MOD_PSERVER. In practice, I've
> looked at the one non-HTTP based protocol they support (mod_echo) and it is
> unclear to me how it would be done. Perhaps it was easy, but the
> documentation wasn't there for me to know.
Quite doable, and Ryan Bloom is actually doing some work this week to
improve the multiprotocol support. While doc will certainly be lacking for a
while, this will be entirely doable.
(it's doable now, but somewhat difficult; Ryan is untangling code so the
non-HTTP-specific support/framework can be used)
> - We could use Avalon. It is written in Java, though, so there would be
> an issue with how the Subversion libraries would be supported.
> * Use JNI to get at the libraries
> * rewrite the libraries in Java
> * Translate the CVS pserver request into a WebDAV/DeltaV request, and
> reissue it to the URL of your choice. This seems the most generic solution.
Seems doable. I'd go with the Apache approach over Avalon :-)
There is a simpler approach, which is the style used by CVS pserver itself.
Use the inetd network daemon system. Basically, your program is started with
a network socket hooked to stdin/stdout.
Below, you mention language APIs. Assume you have a Perl or Python API to
libsvn_fs. Write a script to suck in pserver requests from stdin, process
against libsvn_fs, then write the results to stdout.
Very clean, very easy to test, and because it is script-based, very quick to
write/test/debug/change. I'd take this approach over all others. Recognize
that we don't need the network processing speed of something like Apache. We
already gain the working set efficiency of libsvn_fs over the CVS datastore.
So you're all set.
> There is another possibility here if we were to support commits. Since
I can't imagine a way to unify the two repository models well enough to
support this.
>...
> b) Drop in replacement for CVS
>
> There are many sysadmins with fairly sophisticated scripts for integrating
> the CVS server into their code management and release strategy. It would be
> awfully nice if Subversion knew how to interpret all of the standard files
> in the CVSROOT directory and just worked with them. Perhaps this could be a
> Subversion add-on module in the Apache style.
Interesting point.
We've already considered (and somebody started) a "cvs" command line written
in Perl which just maps everything to "svn" commands.
> c) Linking to Zope
>
> Zope is a great application framework that already supports WebDAV. It is
Actually, it doesn't have very good support, last I checked. And it is very
far from DeltaV.
> written in Python which has an easy mechanism for calling into C code, and
> it already supports many different types of data access. It's own object
> database is versioned. This suggests to me that asking the Digital
> Creations people to support DeltaV and providing an alternative backend for
> Zope could result in some quick wins for everyone, once the Subversion file
> system becomes a little more stable.
I've talked with Paul Everitt (their CEO) about stuff along these lines.
They're certainly thinking about it, and *especially* w.r.t Subversion. Not
sure what he wants private/public, so I'll leave it there. There are
certainly a number of interesting ways to slice this.
Again: this would be a separate effort. Subversion itself will never need or
require Zope.
> d) Wiki
Sounds like CollabNet may be introducing something like this within Tigris.
>...
> We should all make a concerted effort to keep any documentation on
> Subversion as up-to-date as possible. The documentation that exists now is
> really lacking, but with a communal editing effort could be kept in sync
> with the code.
I'll write a disclaimer here, because I know most people don't feel this
way. My opinion :-) ...
I don't need the doc to get my coding done. I'm familiar with all the pieces
that I need to interact with, and then some. I know our end target. All that
is missing is getting the code done. Updating the doc is merely a
distraction. Periodically, I update webdav-usage.html, but that is mostly to
clarify/review my own thoughts.
We aren't at a stage where the code is usable, so doc certainly isn't needed
for users. It might be nice for developers, but I'm not too worried about
that either. We've seen plenty of people come on board with the current doc.
The project started with *four* of us: Karl, Ben, Jim, and myself. All the
rest are "new"; I'd say that we can get additional people even with the
current state of the doc.
</end-of-personal-thoughts :-)>
> e) Mount points in the file system
>
> I have read in a recent message that sub-repositories were argued to death
> and summarily rejected, but I'm at a bit of a loss to understand why. It
They weren't rejected. We'll support them, even in 1.0. You may have misread
a "punt for now" as "punt till 2.0".
>...
> f) Staying flexible enough for alternate uses
This isn't very "actionable", so I can't comment.
>...
> trade-off for the application. While Subversion is initially intended for
> source code control only, is it possible to keep our options open?
Not true. SVN will be usable for any source control needs. I've already beat
Jim up to ensure that we have a way to store and retrieve a gigabyte-sized
file, without loading the whole bugger into memory. We've got some thinking
along those lines, but we'll know more when we sit down to code. I'm
certainly keeping it in mind.
> g) Modular form for Subversion server
Future version. We're going to ship something that can replace CVS. Then
we'll leave it in the dust with kick-ass new features.
>...
> h) Rewriting libs in other languages
>
> Once the API has stabilized, it is important that the ability to access the
Already planned. I'll personally be ensuring there is a Python library.
Lefty said he wanted to work on it, so I'll probably just be assisting
and/or mentoring him with that.
>...
> i) Server controlled UI for conforming clients
Not sure on the utility of this.
>...
> Anyway, those are my thoughts for now. I'd appreciate hearing from anyone
> who has any reaction at all to what I've written, even if it a belief that
> I should just go away with these high-faluting ideas for now while the
> serious work is done.
Ideas are fine, but recognize that we already have an end goal in mind with
a limited/targeted feature set. In that sense, about the best we can do is
to take your ideas and drop them into the IDEAS file. Submitting ideas as a
patch against the file is a sure bet :-)
> I'd particularly like to hear from someone who has
> information or ideas about the CVS proxy idea. Thanks.
Go with the inetd approach. Part of your building block will be your
favorite language API. The API will be a great addition regardless of
where/how the CVS proxy ends up (e.g. in terms of feature richness).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:23 2006