Thanks for the reply,.
Please understand that I didn't mean to offend anyone. I was more
curious than anything, and mainly because of spending a few days
trying to allow my brother to connect to my home server.
Maybe an answer would be a php extension that can interact with
subversion to allow repositories to be controlled more easily.
At work, I have no problems connecting to our server and running
commands to set up repositories and backing it all up. But the server
I use to host my personal websites on is a reseller account, so i do
not have full access.
I would still like to use Subversion on a proper server (and not on my
home line) as it would be faster, and i wouldn't have to leave my
computer on. However, I don't feel that I should have to buy/own a
server to do this.
Making it easier for hosting companies to offer subversion as a
service would be nice a feature of subversion.
I hope you understand what I'm trying say
Richard
(I'm sorry if any of this is already possible as I'm relative
uniformed in the area )
On 19/01/06, David Anderson <david.anderson@calixo.net> wrote:
> 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 13:11:18 2006