Publishing data from legacy svn repository
Hi, I'm working on a project where I need to publish data stored in svn, so instead of coming from the Drupal database, the node body would come from checked out (read only) files on the server (it could be any VCS for that matter). Each file would be associated with a node (automatically or manually), or could be displayed via a different mechanism altogether using an appropriate loader. There is plenty of information on using svn for development, staging or deployment purposes, but I could not find anything on the topic I'm interested in here. Has anyone worked with such workflow and care to share either code or the lessons they learnt? Steph.
On 2010-02-23, at 2:52 PM, Stephane Corlosquet wrote:
I'm working on a project where I need to publish data stored in svn, so instead of coming from the Drupal database
I would suggest having Subversion working through Apache, then you can access the files via HTTP. Later versions (1.5? 1.6?) support accessing revisions by HTTP as well. Then you can also use Apache modules for access control. --Andrew
Andrew, On Tue, Feb 23, 2010 at 3:01 PM, Andrew Berry <andrewberry@sentex.net>wrote:
I would suggest having Subversion working through Apache, then you can access the files via HTTP. Later versions (1.5? 1.6?) support accessing revisions by HTTP as well. Then you can also use Apache modules for access control.
You bring up an interesting approach I didn't think of. In my case, checking out the files locally and keeping them updated by a cron job is not a problem. I think accessing local files would be faster than accessing a remote server via HTTP. Interesting solution if you want to go lightweight and not have to worry about maintaining a local check out. I guess what you meant re access control is that you can use logged in user information to grant them access to pages? Steph.
I haven't used this but it seems similar to what's going on in Feed API module. You might consider implementing a parser, as it might help you with managing your node connections. Dave On Feb 23, 2010, at 12:46 PM, Stephane Corlosquet wrote:
Andrew,
On Tue, Feb 23, 2010 at 3:01 PM, Andrew Berry <andrewberry@sentex.net> wrote:
I would suggest having Subversion working through Apache, then you can access the files via HTTP. Later versions (1.5? 1.6?) support accessing revisions by HTTP as well. Then you can also use Apache modules for access control.
You bring up an interesting approach I didn't think of. In my case, checking out the files locally and keeping them updated by a cron job is not a problem. I think accessing local files would be faster than accessing a remote server via HTTP. Interesting solution if you want to go lightweight and not have to worry about maintaining a local check out. I guess what you meant re access control is that you can use logged in user information to grant them access to pages?
Steph.
On 2010-02-23, at 3:46 PM, Stephane Corlosquet wrote:
I think accessing local files would be faster than accessing a remote server via HTTP.
Yes. For HTTP, if revisions are still being updated, you could cache the response, and when it expires you'll get the latest revision.
I guess what you meant re access control is that you can use logged in user information to grant them access to pages?
If you didn't want the world to be able to view the repository over HTTP, you can use Apache to restrict access to the Drupal server, or set up htpasswd controls. But, since you can have a local checkout, as long as you don't need specific revisions it's probably the best solution. --Andrew
participants (3)
-
Andrew Berry -
David Metzler -
Stephane Corlosquet