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
solution:
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.
-Karl
---------------------------------------------------------------------
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