[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: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-29 21:27:40 CET

On Wed, Nov 29, 2000 at 10:07:08AM -0800, Bill Tutt wrote:
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> 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)

I think that is always the case... one release to the next is not compatible
at the API level. It is just too much of a headache to track API changes,
and you'll invariably miss a change somewhere.

> > 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).

Easier than that. Neon supports SSL already. In fact, somebody reported here
the other day, that they successfully did a "checkout" (from a plain DAV
server) over SSL.

> 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.


The question will simply be feeding the right parameters down into Neon:
proxy, proxy auth, server auth, whether to use SSL, etc.


Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:15 2006

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