On Tue, Aug 2, 2011 at 5:00 PM, Ray Rashif <sc...@archaudio.org> wrote: > 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. > > 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?
I would recommend using something like Jenkins/Hudson (http://jenkins-ci.org). Jenkins will automatically be activated whenever Jenkins detects a change in your Subversion repository for that module. (Basically, whenever someone does a commit). Then, you could have Jenkins do an export of the code, munge it, stop your website, change the files, restart your website, and even run some tests against the website. If there are any issues, Jenkins can mark the commit as "bad" or "unstable" and then email the developers about the issue. Jenkins can run various scripting languages such as shell, MS-Batch, Python, Perl, Ruby, use Ant, MSBuild, Nant, and I am sure a dozen others I don't even know about. I know this may not necessarily fix the problem, but it will alert you of any issues. After a few days with Jenkins, developers will start to be more careful about their commits since they don't like their name associated with bad commits. If you really need to keep certain files out of your Subversion repository, you can use a pre-commit hook to make sure they are never committed in the first place. If a commit contains one of the files you want to keep out, the commit will fail and the user will have to remove the files from their commit. It doesn't take long for the developers to learn to be more careful. I have what I call my Kitchen Sink pre-commit trigger that does all sorts of stuff. One of the tasks it can do is "ban" files based upon their name (either regular expression or Ant glob). If a user adds a file with a forbidden name, the commit is rejected and the user is informed of the offending file. The user has to remove the file from their commit and try again. -- David Weintraub qazw...@gmail.com