3

Currently I have about 5 servers, one I would like to use as a SVN server for development reasons, but I want it to be able to update the external server such as copying committed files to the external server via FTP (or any securer transfer).

Basically when I make a commit to my SVN server with the files that are needed changing it should copy those files from the SVN server to my main site. Is there any method I can do this?

I'm running nginx and Ubuntu 11.04.

MacMac
  • 1,931
  • 8
  • 30
  • 38

2 Answers2

5

It sounds like what you are looking for would be best handled by an SVN hook script. Hook scripts basically exist on the SVN server, and can be used to automatically perform actions, like doing an and updating files.

Though your question mentions FTP I strongly suggest you consider using ssh/scp/rsync instead. You could possibly just have your hook script use SSH and run an svn export/checkout on the other system.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • Do you have any samples of this? – MacMac Mar 03 '12 at 00:17
  • So...? Any samples, point of direction of this similar task? – MacMac Mar 03 '12 at 01:42
  • It depends on exactly what you need/want. There are lots of examples that can be found by using a search on Google for `svn deploy`. While I use a couple hooks in my environment, I doubt they will have any particular value to you or this question. – Zoredache Mar 03 '12 at 02:01
  • @BurningtheCodeigniter - at least name OS, it matter. Two Windows-specific URLs http://www.codersrevolution.com/index.cfm/2008/9/15/Creating-a-postcommit-hook-for-Subversion http://blog.pengoworks.com/index.cfm/2008/2/5/Debugging-Subversion-Repository-Hooks-in-Windows – Lazy Badger Mar 03 '12 at 04:56
  • My OS is Ubuntu 11.04. – MacMac Mar 03 '12 at 13:17
1

Use build tool (Ant, Maven, whatever) and continuous integration tool (CruiseControl, CruiseControl.rb, Hudson, etc).

Do not use hooks for deployment purposes if somebody will recommend it. Specifically in this case hooks approach is wrong because of the several reasons:

  1. Scaling. Hooks do not scale. It is difficult to make hook script do what they are not supposed to as, for example, deployment, which always requires some tricks to perform successfully.
  2. Flexibility. Hooks are not flexible enough. You need to rewrite them every time there are changes in your processes. And your corrections might break something you managed to do with hooks previously.
  3. Security. Are you going to store login/password for ftp/ssh deployment directly in your hook? That will be a huge mistake. You might find workaround, but it will be no good either as long as hooks are not the place for security management.
  4. Complexity. Deployment usually requires a lot of specific actions to do even when at first it seems that it does not. If you start to do deployment in your hook scripts, they will turn out to be swollen and unmanageable.
  5. Source control. You cannot put hooks under source control. If you will try to put it under source control, you will definitely regret it later as long as it is difficult to store hooks together with your project sources, in one place.

All you need to is to:

  1. Write build script where you describe your deployment steps
  2. Install continuous integration tool
  3. Make continuous integration tool use your build script and repository
  4. Configure continuous integration tool to perform build on commit
  5. Perform commit to the repository and see how your changes will be automatically built & deployed according to the build script you've written.

Personally I use Ant and CruiseControl.rb for the purpose you've described. Here is the example of build script to deploy my changes over ftp protocol:

<?xml version="1.0"?>
<project name="myproject" default="deploy-local">
    <property file="build.properties"/>
    <target name="deploy-local">
        <echo message="Deploying version ${version}" />
        <delete dir="${deploy.path.local}" />
        <copy todir="${deploy.path.local}">
            <fileset dir="." includes="**/*" >
                <exclude name=".svn/**" />
                <exclude name="build.*" />
            </fileset>
        </copy>
    </target>
    <target name="deploy-remote">
        <echo message="Deploying project" />
        <ftp action="del"
             server="${deploy.remote.server}" 
             userid="${deploy.remote.login}"
             password="${deploy.remote.pass}">
            <fileset>
              <include name="${deploy.path.remote}"/>
            </fileset>
        </ftp>
        <ftp action="mkdir"
             server="${deploy.remote.server}" 
             userid="${deploy.remote.login}"
             password="${deploy.remote.pass}"
             remotedir="${deploy.path.remote}">
        </ftp>
        <ftp server="${deploy.remote.server}" 
             userid="${deploy.remote.login}"
             password="${deploy.remote.pass}"
             remotedir="${deploy.path.remote}"
             passive="yes">
             <fileset dir="." includes="**/*" >
                <exclude name=".svn/**" />
                <exclude name="build.*" />
            </fileset>
        </ftp>
    </target>
</project>

build.properties file has following content:

deploy.path.local = C:\\apache\\htdocs\\myproject
deploy.path.remote = /http/deploy
deploy.remote.server = ftp.myproject.com
deploy.remote.login = mylogin
deploy.remote.pass = mypass

I would recommend spending some time to learn basics of build management (Ant) and continuous integration (CruiseControl) to perform deployment in a most appropriate fashion. Even though it might seem little bit more complex, it is a right thing to do.

altern
  • 195
  • 1
  • 12