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
>
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.
p.s. Apologies for the re-send - first message didn't go to the list as
well.
---------------------------------------------------------------------
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:32:02 2004