Thanks to Mike (mgm@thoughtworks.net) and kfogel@collab.net
for the suggestions regarding post-commit hooks. I had
investigated this earlier on but had [incorrectly?] concluded
that there was no way to know in the post-commit hook
exactly what file(s) had been committed; being able to
"svn update" only those files and directories that have
changed is definitely the way to go. I'm going to have to
read more in detail about "svnlook"
Regarding K.Fogel's suggestion that the "work area" be a
staging area for the live site, that's actually what we
have planned (I think we're talking about the same thing
here; I probably didn't explain myself well enough.)
If "svnlook" runs at a decent speed then certainly I'll
be able to get "svn update" to run _very_ fast.
Again, thanks.
> --- Mike Mason <mgm@thoughtworks.net> wrote:
>
> Aha. Sounds like you need a post-commit hook that
> goes and updates just the files they've changed on the
> "web" machine. Since we know at commit time what the
> user has changed, we can do a really fast update.
>
> I'm not 100% up to speed on commit hooks, but there's more
info here:
>
http://svnbook.red-bean.com/en/1.0/ch05s02.html#svn-ch-5-sect-2.1
>
> The good thing about a post-commit update hook is
> that the user's commit won't actually finish until the
> update has finished, thus they can go and "instantly"
> see the changed file.
>
> You might still want to run a full update on the
> web area, but could do that during off-peak hours
> or something.
>
> Cheers, Mike.
> --- kfogel@collab.net wrote:
>
> 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
>> --- subversionnewbie@yahoo.com wrote:
>>
>> 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?)
__________________________________
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 21:46:03 2004