On Thursday 19 January 2006 10:16, Richard Lainchbury wrote:
> > Why would svn have to be implemented with PHP and MySQL to be available
> > in hosting packages? I know at least one hoster that offers several VCS
> > with his packages, subversion among them.
>
> Because the other 99% of hosting providers DON'T, if it was done with
> php and mysql then it would more easily available for more people
As it seems nobody else from the dev team replied to this, I'll do so. I hope
I reply for the majority of the developers. I believe I do, from the
reactions and discussions we've had previously. If not, then disagreeing
devs please speak up, and this post will revert to my humble opinion, rather
than our humble opinion.
I won't make a secret of the fact that your statement/question sent a wave of
shock and horror through us. This is for two main reasons.
First of all, the issue of PHP. Most of the developers have had a taste of
one of Python, Lisp and Ruby (among others), and are of the opinion that PHP
has the uncanny talent for condensing within itself the very worst out of all
of them, without the good parts. On good days.
Indeed, its only redeeming feature imho is that most "free" hosts offer it,
because it is believed to be "safe" (not true for many setups) and that it
will bring them business, because "Everyone knows everyone wants PHP", a
marvellous Catch 22 that ensures that PHP will continue to live way beyond
its nominal lifespan.
Therefore, the very idea of implementing *anything* in PHP is something for
which you'd have to find another dev team. The idea of implementing a robust
revision control system in PHP is something that I honestly doubt is at all
possible. Implementing a robust and *fast* revision control system in PHP
seems like downright science fiction. We are already not satisfied with the
performance of some areas of the code, and this is for code that is in C, ie.
supposed to be as pedal-to-the-metal as you can get without writing in Asm.
In PHP, I reckon we'd be marvelling at any piece of code that would run at
all within the 30 seconds allocated to an instance of the PHP interpreter.
Of course, I for one would love to be proven wrong on this. If Subversion can
be implemented in PHP and yield equal or superior performances, I will gladly
eat my words. Seeing is believing they say, and maybe one day I will see.
But until then I certainly won't believe :-).
Second is the issue of MySQL. For this, I'll assume that you mean that this
PHP-Subversion should use a MySQL database to store revision data. This is
not something new to us. If you look at our roadmap page, one of the
long-term goals is to implement a SQL database backend for Subversion, to
complement the current BerkeleyDB and FSFS backends.
Why is this long term? Because our backends are storage systems that store a
versionned file system, which is a series of interconnected DAGs (Directed
Acyclic Graph, the fancy way of saying a tree).
This is a problem, because SQL is great at many forms of data crunching, but
representing a tree is one thing it is definitely not good at doing. There
are algorithms which make it fairly easy to represent a single tree in a SQL
database, with fast read access to subtrees, but slow write access (an update
on anywhere up to all rows is required when inserting new nodes). And that
structure does not account for multiple intertwined trees, which will no
doubt make the overall structure even more complex, and therefore likely to
be slower (though I'll reserve my judgement on that, depending on the design
SQL can be surprisingly fast in some cases).
So, storing a sequence of interrelated trees in a SQL database is a Hard
problem, and that is why we don't yet have a SQL backend for Subversion.
That is also why it is listed as a long-term goal, after things that are also
hard, but not as much, and have higher yield.
Those are the two main reasons why I believe a php+mysql subversion
implementation is less likely to happen than the sun suddenly taking on a
sharp pink-with-blue-stripes tint on a whim. There are other reasons, but
the two above are showstoppers enough to avoid further exploration.
While I see the argument for having such a thing in terms of possible
"clientèle", the technical constraints linked with an efficient revision
control system are rather incompatible with the characteristics of php and,
to a lesser degree, mysql.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 19 12:51:28 2006