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. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
