[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: <kfogel_at_collab.net>
Date: 2004-11-16 01:09:42 CET

Subversion Newbie <subversionnewbie@yahoo.com> writes:
> 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?)

Better solution: have the "work area" be a staging area for the live
site, so that their changes are visible to them right away (if they
visit the staging URL, of course).

The only other thing I can suggest is this two-part workaround

   1. Have a post-commit hook that uses 'svnlook' to find
      out exactly what files/dirs changed in a commit, and
      use that information to drive targeted updates in the
      live-site working copy. The targeted updates will
      be faster, because they're operating on named targets,
      so that the whole working copy's state doesn't need
      to get reported to the server.

   2. At the same time, have a periodic cron job that
      updates the entire site, just to be safe :-).

Splitting your data into several repositories is not necessary, with
this scheme.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 16 01:16:11 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.