# Handling svn:externals?

**URL:** <https://www.ruby-forum.com/t/handling-svn-externals/83257>\
**Category:** Deployment\
**Created:** [January 24, 2007, 6:27pm UTC](https://www.ruby-forum.com/t/handling-svn-externals/83257 "2007-01-24T18:27:55Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![superwick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/46a35a/32.png) [@superwick](https://www.ruby-forum.com/u/superwick)\
**Post date:** [January 24, 2007, 6:27pm UTC](https://www.ruby-forum.com/t/handling-svn-externals/83257/1 "2007-01-24T18:27:55Z")

</div>

Hi,

I’m new to the group, so I’ll start off with a huge post 🙂

How do all of you handle deploying projects with svn:externals?  
Basically, the problem is that externals always point to the trunk  
unless you explicitly “freeze” them to a specific revision. This  
means that even if you make a tag (svn cp) and deploy that, the next  
time you deploy that same tag (or svn up) you’ll get the latest  
‘trunk’ of externals, NOT the version of the externals that existed at  
the time the tag was made.

Our group has written custom code around Capistrano do deal with this  
issue. We call this our “cut” process, which we do by automatically  
branching, then ‘freezing’ the externals on the branch, then tagging  
the branch. Then, we can deploy or branch off of this tag, and the  
externals will always be frozen to the same revision that they were at  
when the branch was originally made.

This “cut” process is automatically performed by our Continuous  
Integration process after each green build. So we can always grab the  
tag from a green CI build, and know that it has frozen externals and  
is good to deploy.

Since we wrote our custom code, the “Piston” project has since come  
out which does a lot of this same thing. Does anyone have a cool  
integration for Piston into their project or Capistrano? Any public  
examples of capistrano recipes that use Piston?

One other issue is how to automatically do this for any externals  
which exist, across multiple projects. If different projects have  
different externals, this must be manually managed on a per-project  
basis. Even with Piston, you have to explicitly specify the commands  
for each different external. So, has anyone go as far as  
automatically determining which externals exist for a project, and  
having some wrapper code for Piston which will perform the commands on  
all of them. This doesn’t seem too hard, but we are not using Piston  
yet, so we haven’t played with it.

Thanks,  
– Chad W.

---

<div class="post-metadata">

**Author:** ![superwick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/46a35a/32.png) [@superwick](https://www.ruby-forum.com/u/superwick)\
**Post date:** [January 24, 2007, 7:23pm UTC](https://www.ruby-forum.com/t/handling-svn-externals/83257/2 "2007-01-24T19:23:09Z")

</div>

Chad W. wrote:

> automatically determining which externals exist for a project, and  
> having some wrapper code for Piston which will perform the commands on  
> all of them. This doesn’t seem too hard, but we are not using Piston  
> yet, so we haven’t played with it.

Piston will update _all_ of your svn external plugins within a project  
with the convert command.

$ piston convert

[http://www.robbyonrails.com/articles/2007/01/16/every-second-counts-with-a-piston-in-your-trunk](http://www.robbyonrails.com/articles/2007/01/16/every-second-counts-with-a-piston-in-your-trunk)

Cheers,

-Robby

–  
Robby R.  
[http://www.robbyonrails.com/](http://www.robbyonrails.com/)

> **[Planet Argon](https://www.planetargon.com/)**
>
> Planet Argon is a Ruby on Rails development agency specializing in maintenance and support for existing Rails apps. Based in Portland, OR, Planet Argon has been a member of the Rails community since 2004.