On Sat, 30 Jul 2011 18:30:11 +0000, Ryan Schmidt wrote:
> But you understand why even if I knew I would be disinterested in helping you. The Subversion libraries have been in development for 11 years, work great,
They work so great that you can't even Ctrl-C the svn command line client
in the connection phase, and instead need to resort to ^Z and 'kill -9 %'.
(Ok, this may not actually be a problem with *lib*svn.)
> The Subversion libraries are going to continue to evolve, as is the network protocol. For example, Subversion used to only be able to use neon for talking to http servers, but now can use serf which perhaps offers better performance, and serf becomes the default in Subversion 1.7; which of these methods are you emulating?
If he is going to talk on the level of http requests directly,
neon-vs.-serf is a complete non-question.
The interesting point is that as far as I know there is a complete change
in the http-level protocol coming up, to avoid the massive round-trip
count the current method needs. (But that's a maintenance nightmare
for libsvn as well as for anybody else writing a bare-net client.)
> So this isn't even a one-time task you're contemplating; this is an ongoing duplicate maintenance effort you're committing yourself to.
Yes, it is. But it's not your problem, and I don't see why the http
'wire' protocol needs to be a undocumented secret. Using a C library is
*not* always an option; for example having a pure java client library
available would be a big help for java-implemented IDEs.
And there already *are* parties that talk svn http directly; github has
readonly svn access, and codeplex is also emulating somehow. Neither do
I expect google code to use the original apache svn server code.
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2011-07-31 05:35:23 CEST