[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: how to deal with HUGE repositories?

From: Felix Gilcher <gilcher_at_exozet.com>
Date: 2004-11-17 17:14:12 CET

> -----Ursprüngliche Nachricht-----
> Von: Konrad Rosenbaum [mailto:konrad@silmor.de]
> Gesendet: Mittwoch, 17. November 2004 14:30
> An: users@subversion.tigris.org
> Betreff: Re: how to deal with HUGE repositories?
> 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 https://mydomain.com/svn/site1/trunk
> ...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.
> Konrad

for me it seems this rather non-trivial for the following reason: Most websites
are not build in pure html any more, so when you access the site via you browser
you get the source code that generates that page. This is most probably not what
you'd like to see. You could most probably rig apache up to interpret the source
code for you, but this would

a) break references to libraries that are included in the repository (included php
files etc. unless you use something like url_fopen_wrappers to read source code
from http which is usually considered as something you shouldn't do for security

b) a normal checkout via http(s) would be interpreted as well which is something you
really don't want to happen...

And then there is another gotcha: The mime-type that apache sends when you access
svn-repositories is text/plain. A somewhat standard-compliant browser will not try
to render this page (i just checked, even the notorious IE handles this properly).
One could certainly tweak apache/mod_svn to send another mimetype, but then you'd
still have to solve the other two problems. There are some more issues that I can
think of ...




To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 17:15:14 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.