Re: Subversion transactions within post-commit

On Tue, Aug 2, 2011 at 5:00 PM, Ray Rashif <schiv_at_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
qazwart_at_gmail.com