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

Re: how to deal with HUGE repositories?

From: Subversion Newbie <subversionnewbie_at_yahoo.com>
Date: 2004-11-16 00:57:45 CET

Hi Mike,
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?)

Splitting up the huge collection into several
repositories means that each "svn update" (to the the
web area) runs a lot faster than an "svn update" of
one huge repository (based on our tests).

And no, we're not worried about inconsistencies and do
appreciate the atomicity of SVN's operations :-)

Thanks again for your help.

--- Mike Mason <mgm@thoughtworks.net> wrote:

> Hi there,
>
> I'm trying to figure out why you need the "svn
> update" to be really
> fast. I can see why if it's really really slow it's
> a bad thing, but why
> d'you want it on the order of a few seconds, and why
> does splitting
> things up by subdirectory help?
>
> My best guess is you're worried about getting an
> inconsistent checkout
> if someone's checking in whilst the update is
> running. Thanks to the way
> Subversion works internally this isn't a problem --
> an update always
> leaves your repository at a particular revision. If
> someone checks in
> whilst the update is running you just won't get
> their changes. It's just
> like database transactions -- you'll see a whole
> commit or none at all,
> not something in the middle.
>
> Does this help?
>
> Cheers,
> Mike.

> Subversion Newbie wrote:
>
> >We have website that currently contains about 94000
> >files (in 7200 directories) for a total of about
> 1.6
> >GB. Our plan is to move all this to an SVN-based
> >repository scheme.
> >
> >Our proposed scheme is to have a "work" area (from
> >which users check stuff in and out via TortoiseSVN)
> >and another "web" area which is essentially
> Apache's
> >DocumentRoot. Users will check files in/out from
> >"work" into the repository, and a script will
> >periodically "svn update" from the same repository
> >into the "web" area so that the updated files are
> >visible to Apache.
> >
> >Currently, the "svn update" into the "web" area
> takes
> >WAY too long, for the obvious reasons. Our goal is
> >for "svn update" to take no more than two or three
> >seconds
> >
>

                
__________________________________
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 Tue Nov 16 00:58:10 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.