I know Karl would dearly love this thread to die on this list, but
really, all of what I'm going to say is very directly tied to
Subversion, although it's all post-1.0 stuff.
There are two issues to consider. First, language bindings. This
isn't really a question. If Subversion becomes popular, someone will
do language bindings in perl. We can host them in our CVS tree or
not; it doesn't matter especially much. Very low commitment on our
part.
Second, server triggers. We have a high-commitment option with regard
to server triggers, which is linking the perl interpreter into the
server as a compile-time option, and making perl code a form of server
trigger. If and when it comes time to decide whether to do this, I'd
consider the following as axioms:
* Server triggers are usually not very complicated, at least
if Subversion has done a good job providing the
fundamentals. (CVS does not, and I've seen some rather
complicate perl trigger scripts as a result.)
* Regardless of what developers think, perl is a really really
big favorite among Unix system administrators.
It may be enough to just let people call out to perl scripts via the
shell, or it may not. Aside from performance, linking perl into the
server has the advantages that (a) getting at interesting Subversion
values can be made more direct, via perl global variables, instead of
having to pass them through arguments to the script, and (b) people
can more easily keep state between trigger calls. Or so I would
guess; I'm not actually too familiar with the perl interpreter
interface.
For the record, I despise perl as a development language and agree
with all the bad things people have said about it here, although I do
use it from time to time. But I won't go into detail.
Received on Sat Oct 21 14:36:24 2006