Use of database for SCM

[Valentino Volonghi aka Dialtone]

John A Meinel wrote:

> Aside: please Reply-to-all so that the replies go back to the list.

Ops... sorry

> Valentino Volonghi aka Dialtone wrote:
>
>> John A Meinel wrote:
>>
>>  
>>
>>> POST/PUT are perfectly standard HTTP to send some data to a CGI script.
>>>   
>>
>>
>> Not really... even BaseHTTPServer can handle POSTs and PUTs (not to tell
>> Twisted.Web(2)
>> since I see it was mentioned some time ago).
>>  
>>
> Sure, but BaseHTTPServer is a special server that you put. It is not
> Apache which is already serving a normal web-page. At current remote
> putting of files isn't supported because it requires something on the
> server side.

Right, but a local server proxypassed from apache could do it anyway :)

>>> Which means that you have to have some sort of customized software
>>> installed on the server side.
>>>   
>>
>>
>> Nothing like that AFAIK. If you have the webview of your repository it
>> is quite easy to write
>> the support for POSTs and PUTs to modify files through HTTP.
>>
>>  
>>
>>> At least that is my understanding. Is it truly possible that without
>>> configuring a cgi script you can push files over http into a directory?
>>>   
>>
>>
>> I do that every day with Twisted and Nevow. HTTP is a very very very
>> rich protocol full of
>> potential that nobody actually uses at 100% of its capabilities.
>>
>> Let's do an example. You send patches as the body of the request at url:
>>
>> http://www.example.com/myproj/trunk/file1.py
>>
>> The request will be:
>>
>> PUT /myproj/trunk/file1.py HTTP/1.1\r\n
>> Some-Headers: Bla bla\r\n
>> \r\n
>> --- e.py        2005-06-20 19:26:02.000000000 +0200
>> +++ err.tac     2005-05-28 02:42:15.000000000 +0200
>> @@ -1 +1,117 @@
>> -print 'sennò non vale :)'
>> +from nevow import appserver, rend, loaders, tags as T, inevow, context
>> +from twisted.internet import defer
>> +from twisted.application import service, internet
>>
>> And the server will read the content and apply the content to the file
>> specified in the path requested.
>> This doesn't seem hard at all. at least to me.
>>
>>  
>>
> It is simple *if* you are running a server which supports PUT. The
> whole point is that it is possible for bzr to support remote
> filesystem access without a custom server.

Ok, fine enough.

>>> ftp/sftp etc obviously support that sort of thing.
>>>   
>>
>>
>> you don't need to send files, most of the times you just need to send
>> patches, and anyway FTP and HTTP
>> may, and in fact do, overlap a bit in their functionality.
>>
>>  
>>
> Certainly. But http with a normal "Apache" style server doesn't let
> you upload a file. While ftp does.
>
>>> Right now bzr is considering the best way to handle remote filesystem
>>> access, since you want to do the right thing when it comes to locking
>>> files.
>>>   
>>
>>
>> Instead of thinking about the best way (which means nothing) I think the
>> main effort should be on a flexible
>> system that can work with different protocols, even if initially you
>> will just implement the one you most like.
>>
>> Obviously, since I'm not partecipating in this project you should feel
>> free to ignore my thoughts :).
>>
>>  
>>
> That it certainly what is planned. Right now we have an abstraction
> interface, which is being slightly redesigned to better support
> pipelined & asynchronous access. And to better allow
> pluggable/multiple storage mechanisms.
> There was some discussion as to where the best place to actually have
> the code. And because there might be more than 1 storage on disk
> format, not to mention more than one transport mechanism. (One of
> which is a smart server, dedicated to bzr, others are http,sftp,ftp,etc).

I see, well done then. Thanks for your answers and kindness :).

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4.1
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de