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.
Right!
The question will simply be feeding the right parameters down into Neon:
proxy, proxy auth, server auth, whether to use SSL, etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:15 2006