[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn_ra.h

From: Bill Tutt <billtut_at_microsoft.com>
Date: 2000-11-29 19:07:08 CET

From: Greg Hudson [mailto:ghudson@MIT.EDU]

> > Greg S. wrote:
> > It buys us a way to support third parties who want to create
> > repository access layers.

> Here's a question: would we rather support third-party layers through
> a dynamic linking interface or through a subprocess? A dynamic
> linking interface would mean fixing a programmatic ABI (symbol
> versioning whenever structures change, all that good stuff). A
> subprocess interface requires marshalling and unmarshalling all of the
> relevant data, but we've already done that work (XML deltas) in
> libsvn_subr.

Taking a COM interface revision model when possible is probably the easiest
way.
e.g. Adding appropriate members in the editor function pointer structure to
access
newer interfaces.

New editor function pointer structure members:
unsigned int cExpansions;
// Sorted array of interface extensions, sorted by InterfaceRevision.
// apExtensions[InterfaceRevsision-1] will yield
// a pointer to the new function signatures.
void **apExpansion;

Given SVN's current state, it's probably not worth worrying about atm
though.
There's too many backward compatibility breaking changes in the near term
future.
  
Symbol versioning stuff will just lead you into insanity land preserving
backward
compatibility. That seems like more work than necessary for this sort of
open source
code project. (as opposed to libgcc, or libc)

> Also, I want Subversion to work over rsh/ssh at some point (unless you
> can provide neon and apache with authentication mechanisms which have
> all the nice key management properties of ssh), which means I want the
> subprocess support anyway.

Well, I'd think the preferred approach would be to support SSL secured
mod_dav_svn use. In which case, hopefully the only real work you'd
have to do would be to tweak libsvn_ra_dav to be able to optionally
use an SSL package, (or SSPI on NT).

The idea being, that mod_dav_svn, and neon, etc, wouldn't have to care
about all of this goop. This way libsvn_ra_dav is still HTTP proxy
happy, and you don't have to let ssh through your firewall if you
don't have to.

Bill
Received on Sat Oct 21 14:36:15 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.