views:

455

answers:

2

We're testing the waters with SVN, with Beanstalk as a host. Our setup looks something like this:

  • Repository: Modules

    • Module 1
    • Module 2
    • Module 3
  • Repository: Website 1

    • Custom website code
    • svn:External reference to Module 1
    • svn:External reference to Module 2
  • Repository: Website 2

    • Custom website code
    • svn:External reference to Module 2
    • svn:External reference to Module 3

Beanstalk has built-in FTP deployment tools. In my ideal world, Beanstalk would just see the external references and deploy any changes to the modules along with the website changes, but this isn't supported and won't be anytime soon.

What's a good practice for automatically deploying Websites 1 and 2 in a way that changes to the external modules are included?

Do other SVN hosts have better support for deploying externals?

If possible, I'd like to avoid adding our own build/deploy server.

+1  A: 

If the deployment uses export, then that might make sense; I'm pretty sure the latest version of SVN also exports externals, but earlier versions did not. Perhaps your best bet would be to perform a checkout of the repository in question on your deployment server and update from there? If you use branches and tagging, you might also create symlinks to your webroot that point to different releases in the checkout.

Typeoneerror
We ended up doing something like this, using CruiseControl.net.
Herb Caudill
+1  A: 

Why not checkout the svn repo to the local machine, and do an svn update and commit which will bring beanstalk up to date. Then do a deploy via beanstalk. You could schedule a script to svn udpate everyday.

aleemb