[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion transactions within post-commit

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 3 Aug 2011 15:24:05 -0400

On Wed, Aug 3, 2011 at 2:31 PM, Ray Rashif <schiv_at_archaudio.org> wrote:
> On 4 August 2011 01:59, David Weintraub <qazwart_at_gmail.com> wrote:

> Thanks guys. I'm just stupid. I've been going on and on about what we
> want to do, but I haven't even stated the obvious:
>
> * It's just about removing stale files from being tracked by
> Subversion, _without_ committer intervention.
>
> Basically, our developers (did|can do) this thing manually (remove an
> older version of a binary they are committing). I wanted to automate
> this. That's all!

Is this binary file a file that's built out of your source code? If it
is, it shouldn't be in your repository at all. Instead, it should be
built when the deployment is needed.

That's what Jenkins and Hudson can do for you. When the code is
checked in, they'll do the build, recreate the binary, and do
deployment automatically. Your developers can go to the Jenkins/Hudson
webpage and download the deployment including the built files. Since
Jenkins/Hudson can store multiple builds, there's no need for any
built objects to be stored in your source code.

Jenkins and Hudson are simple to setup, easy to use, yet very powerful
tools. Take a look at http://jenkins-ci.org.

(Jenkins and Hudson are a forks off the original Sun project called
Hudson. Oracle bought Sun, and the main developer of Hudson left and
took the code with him as well as most of the other developers. Oracle
owns the Hudson name, so the developers renamed the project Jenkins.
Now, both projects claim they're the original and the other is a mere
fork. As of now, most of the activity is on Jenkins which is what I
use.)

-- 
David Weintraub
qazwart_at_gmail.com
Received on 2011-08-03 21:24:36 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.