On Wed, Sep 7, 2011 at 10:13 AM, Marco Strullato
<marco.strullato_at_gmail.com> wrote:
> I would like to configure subversion so that when a user commits
> a binary file, it would be automatically stored in a remote place (i.e. ftp).
Are you trying to prevent a binary file from being added into your
repository, or if someone does add a binary file to your repository,
you also want to move it to a remote storage location?
A pre-commit hook to prevent the addition of a binary file may not be
that bad -- as long as the pre-commit hook also didn't ftp it
somewhere else.
For example, I can imagine preventing someone from adding in the
compiled project into Subversion. However, what about binary files
such as jpgs and gifs that are true source files? You probably want
users to add those into Subversion.
As for the FTP part, don't do it. Not in a hook. A hook script must
complete execution before it returns control to the user who fired off
the `svn commit` command. If it takes two minutes to FTP the file,
your user is sitting there for two minutes waiting for the commit to
complete and wanting to know why Subversion is so slow.
If you can clarify exactly what you want and why, I might be able to
make a more solid recommendation. For example, let's say a developer
checksout the code, and compiles it. You want to store the compiled
version in Subversion, and at the same time, move this compiled
program to an FTP site for downloading.
My suggestion is to tell you to get a continuous build system like
Jenkins and let Jenkins handle the builds. Don't store the compiled
code in Subversion. Jenkins can store the compiled program for
downloads, and/or FTP it over to your release repository. We use
Jenkins for our release repository by storing the compiled programs in
Jenkins build artifacts. Jenkins automatically cleans out old builds
except those we marked as released.
--
David Weintraub
qazwart_at_gmail.com
Received on 2011-09-07 18:44:04 CEST