Hmmm.. I've been doing some more research, and think that Apache's
handler directives might be useful. Using these, I can route any
requests through a Perl script.
However, I'm afraid dav_svn might get in the way. Do you or anyone else
know if dav_svn will override any custom handlers I create? It must at
least be overriding the default handlers so that the browser just ends
up with the source, rather than interpretting the HTML. Might using a
virtualhost proxy circumvent this problem?
The other problem is getting any added content out again when it's
committed back. As of yet, I haven't seen how to declare a handler for
WebDAV writes. If I could do that, it would be trivial to extract the
pertinent information only.
Thanks again,
Ian
P.S. The SVN repo browser I've looked at is just a PHP script that reads
the repository and parses it for the client. Since there's no need for
DAV's write capabilities, this doesn't give much of a clue.
Phil Endecott wrote:
> Ian Smith-Heisters wrote:
>
>> Hi all,
>>
>> I've written a web site that uses the PHP directive
>> "auto_prepend_file" to automatically give every file in the site a
>> certain include file. Thus, every file is pure, virgin content.
>>
>> The site is stored in an SVN repo, served with Apache2 mod_dav_svn.
>> When a client requests a file from SVN they receive a file that
>> doesn't have any of the PHP whatnot included, ie. the source code,
>> which is good in most cases.
>>
>> However, there is a WYSIWYG editor (Macromedia Contribute) that needs
>> the layout information contained in the PHP include in order to
>> provide a user-friendly experience.
>>
>> Is there any way to make dav_svn (selectively) parse PHP? Is there
>> perhaps just a way to just slap some text onto the top of certain
>> files when they're requested (eg. a CSS include, so that Contribute
>> will at least render styles)? Can SVN's WebDAV do any browser
>> detection? Perhaps using a pre-checkout script to detect the client,
>> throw in layout info, then a pre-checkin to remove the layout info?
>
>
> Look for a solution within Apache but outside the SVN code. I don't
> know exactly how to solve this, but it will involve another Apache
> component (PHP? Filters? mod_something?) doing a sub-request (or
> whatever the Apache terminology is) that is handled by Subversion's
> modules in the normal way, and then processing the result of that
> sub-request before returing it to the browser.
>
> Look, for example, at how the various Subversion web-based repository
> browsers work. They can present HTMLified program source code which has
> been colour-coded according to the language's syntax rules; this is done
> by getting the raw code from Subversion and then processing it before
> returning it to the browser.
>
> You certainly don't want to be doing it using hook scripts.
>
> Good luck!
>
> --Phil.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 8 21:39:26 2005