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

Re: AW: how to deal with HUGE repositories?

From: Subversion Newbie <subversionnewbie_at_yahoo.com>
Date: 2004-11-17 17:40:25 CET

Felix, thanks for the comments. What Konrad proposes definitely
has some problems, although I could imagine a few Rewrite rules
that would allow us to get around some of them. However, I can
also imagine that it would become one big kludge :-)

--- Felix Gilcher <gilcher@exozet.com> wrote:
>
> > -----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
> >
>
> Hi,
> 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
> reasons)
>
> 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 ...
>
> regards
>
> felix

                
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
 

---------------------------------------------------------------------
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:40:55 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.