On Tue, Aug 2, 2011 at 5:00 PM, Ray Rashif <schiv_at_archaudio.org> wrote:
> On 3 August 2011 04:37, David Weintraub <qazwart_at_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
>
Received on 2011-08-02 23:47:42 CEST