Igor Burilo wrote: > > C. Michael Pilato wrote: >>> Our goal is to bring our Serf integration up to the quality (in terms of >>> both user experience and proper API adherence) of our Neon one so that > Serf >>> can safely become the new default DAV RA implementation, yes. It's mostly >>> there, but still contains a few gotchas. We've switched our trunk >>> (1.7-aimed) code to use Serf as the default if both it and Neon are found, >>> but that change could be reverted (restoring the use of Neon as the > default) >>> if we aren't able to iron out the Serf integration shortcomings in a > timely >>> fashion. > > Michael, this is a very good news and it's good that you work on it now, > because licensing issues (Neon license incompatibility) are very important > for us. Hope that you will manage to do it if for SVN 1.7. > > Thanks, Igor
I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
