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.
on 2007-01-24 19:27
on 2007-01-24 20:23
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/ev... Cheers, -Robby -- Robby R. http://www.robbyonrails.com/ http://www.planetargon.com/