On Tue, Aug 2, 2011 at 5:00 PM, Ray Rashif <sc...@archaudio.org> wrote: > On 3 August 2011 04:37, David Weintraub <qazw...@gmail.com> wrote: >> NO! NO! NO! AUUUGGGHHH! >> >> Never update a repository with a hook.! That's why you're given the >> relatively safe "svnlook" command. It allows you to look, but not >> touch a repository. >> ... >> SNIP >> ... > > Arrrgghhh damn it! Exactly what I feared. Especially the recursion. So > much so that now I think I was in denial all the while. > > OK, looks like I have to explain a bit further to clear this up and > hopefully get some solutions. > > We use the repository to directly serve some files (so Subversion > updates are immediately reflected). Something like > http://subversion.apache.org/faq.html#website-auto-update > > So $files.subdomain.org/public_html is actually a local checkout of > $svn.subdomain.org/public_html/trunk/$somedir, and whenever someone > commits something to the SVN repo, the post-commit hook updates the > local checkout. So anyone browsing the file server will get the most > recent files.
That's what "svn checkout" for initial setup, and "svn update" or "svn revert" of the local copy are for. > However, we need to be a bit more personal than that. We need to do > some checks on those files and remove ones that should not be there. > We need to do this immediately after the commit, so cron is not an > option. How should we go about doing this? Then you do your updates in a working copy as part of a working copy, and that copy has a deployment script or "Makefile" that does "rsync" or other mirroring tools to publish those changes to your exposed website. I like "Makefile" bassed approaches, myself, so I can do "make", "make test", and "make install". > > -- > GPG/PGP ID: 19BAA7AD >
