On 29/06/2007 6.05, Blair Zajac wrote:
>>> And this time (if you allow me my humble two cent) get it right and
>>> cut the
>>> development time down to 1/10th by using a more evolved language than C.
>>> Python comes to mind, but anything would do.
>>
>> One thing I'd hope we avoid with "Subversion 2.0" is second system
>> syndrome and such a desire smacks of it.
>>
>> Moving away from C means we'd most likely remove all reasonable
>> extensibility mechanisms. One of the reasons that I view SVN as a
>> success is that we made it fairly simple for third-parties to
>> integrate with SVN - C is by far the best language for that.
>>
>> Rewriting all of Subversion in Python/C++/Java/Ruby is also *way*
>> easier said than done. As we discussed at the summit, I don't have a
>> problem with the higher-level parts - such as the command-line client
>> - being implemented in Python which wraps around C libraries. But,
>> libsvn_wc, libsvn_repos, etc. only being accessible via Python? Yuck.
>> -- justin
>
> Agreed. I couldn't integrate the Subversion filesystem into a new asset
> management system supporting thousands of RPC calls per second if it
> wasn't in C and I couldn't link it to Ice or anything else I needed.
Please don't overstate what I proposed. I'm speaking of wc only (no repos, no
ra, etc.). And only because libsvn_wc is going to be rewritten from scratch
anyway.
Right now, the wc specifications are "private" and third parties are supposed
to access wc only through the libsvn_wc API. I find that mostly inconvenient.
I'd rather the wc specifications to be public and official, and have a
testsuite to certify wc implementations. After that, there's no reason we
should code our wc implementation in C.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 29 10:13:07 2007