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 <email@example.com> 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?
> Subversion Newbie wrote:
> >We have website that currently contains about 94000
> >files (in 7200 directories) for a total of about
> >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
> >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
> >WAY too long, for the obvious reasons. Our goal is
> >for "svn update" to take no more than two or three
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 16 00:58:10 2004