Konrad, thanks for your feedback. I had always thought that
it's more complicated than that for the following reason: The
files that are checked in by the users are typically files that
include others, or included by others (using SSI or PHP) so they
have to be viewed through the webserver whose DocumentRoot
contains the "svn update"'d version, and not directly from the
WebDAV. However, now that I think about it, I'm wondering if I
can in fact integrate the full functionality of the web server
(PHP, SSI, various Rewrite rules, etc.) into the same
Apache2/WebDAV server and have it all be served together (except
for the "svn...trunk" stuff that would go in the URL; have to
think about that one.) Regards.
--- Konrad Rosenbaum <email@example.com> wrote:
> On Tuesday 16 November 2004 00:57, Subversion Newbie wrote:
> > The reason why we need "svn update" to be really fast
> > is: after a user "checks in" a modified file, she'll
> > want to view it through the website very shortly
> > afterwards. If there is a substantial delay (let's
> > say more than 4 seconds after commiting the changed
> > file) then we'll have complaints. These expectations
> > are based on the current way of doing things, where
> > users change files on what is basically a live
> > website. (Not a pretty sight, huh?)
> That is trivial if you use Apache2/WebDAV as server protocol.
> Let's assume your repository is
> ...tell your users to enter just this URL into their browser
> to have an
> online preview. The "GET" request issued by a normal browser
> is identical
> to what subversion issues to get the newest version, so you
> always see the
> newest version of your repository if you look at it with a
> normal browser instead of subversion.
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 17 15:44:56 2004