# Capistrano: update instead of checkout? **URL:** \ **Category:** Rails\ **Created:** [May 19, 2006, 6:17pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053 "2006-05-19T18:17:09Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 19, 2006, 6:17pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/1 "2006-05-19T18:17:09Z")
Hello, Just started to use Capistrano for deployment and everything works beautifully and as advertised. Thanks Jamis for this great piece of software. However, in my case, the deploy task takes quite some time since my SVN repository resides on a different continent than my app/db server and I’ve frozen all the rails code in the vendor dir and checked in. All in all my app sums up to about 40M. The svn checkout of the code takes about 5 minutes. That’s no big deal for regular deployments of new versions of the application. But of course there will be a typo somewhere in the app side of my newly deployed site. Fixing it is easy, deployment too - but compared to the time I needed to correct the error, deployment takes far too long. Furthermore I mind the spoiled bandwith - transferring 40M just because one letter changed is not really gentle. The sideeffect of this: I postpone the deployment of minor and uncritical bugfixes. And that’s an attitude I doesn’t like either 🙂 I guess I could customize the Capistrano update\_code recipe so that it performs a 1. copy -r \ \ 2. svn update \ (given that the \ is a checkout and not a svn export, of course) Somehow sounds too easy … My question therefore: can somebody tell me why this would be a bad thing to do? If it would be so easy and without drawbacks, why isn’t it the default behaviour of Capistrano then? What am I missing? Thanks a lot & regards Thomas ---
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 19, 2006, 6:51pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/2 "2006-05-19T18:51:41Z")
On 5/19/06, Thomas W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > My question therefore: can somebody tell me why this would be a bad thing to > do? If it would be so easy and without drawbacks, why isn’t it the default > behaviour of Capistrano then? What am I missing? A better question is why do you have 40 MB of source code for a website? If this is mostly images, you could have those in the shared directory and deploy only the source code via your default Capistrano task. – James ---
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 19, 2006, 7:13pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/3 "2006-05-19T19:13:28Z")
James L. \ writes: > A better question is why do you have 40 MB of source code for a > website? If this is mostly images, you could have those in the shared > directory and deploy only the source code via your default Capistrano > task. As I said: I’ve checked in rails and a bunch of plugins: % du -sh vendor/ 32M vendor All the image data already resides in public/system and is linked to shared therefore. Of course one could argue to put some of the vendor stuff to shared, too. But that makes the whole thing complicated. And simplicity is the reason why Capistrano itself deploys everything to app, db and web although not everything is needed everywhere. If I get efficiency “for free” in just using update instead of checkout, that’s certainly the path I would prefer. But thanks for your suggestion anyway! ---
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 19, 2006, 7:20pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/4 "2006-05-19T19:20:44Z")
Thomas W. wrote: > …The sideeffect of this: I postpone the deployment of > minor > and uncritical bugfixes. And that’s an attitude I doesn’t like either > 🙂 > > I guess I could customize the Capistrano update\_code recipe so that it > performs a > > 1. copy -r \ \ > 2. svn update \ > > (given that the \ is a checkout and not a svn export, of > course) > > Somehow sounds too easy … For minor revisions, why not just ssh to your server, change to the appropriate directory, and “svn update”? I don’t see why your proposed change wouldn’t work, but doing it manually might be just as easy. –Al Evans ---
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 20, 2006, 4:25pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/5 "2006-05-20T16:25:37Z")
On 19 May 2006, at 19:08, Thomas W. wrote: > 32M vendor > You can use the following tip to help manage your vendor/rails. > [http://rails.techno-weenie.net/tip/2006/2/7/](http://rails.techno-weenie.net/tip/2006/2/7/) > deploy\_your\_apps\_on\_edge\_rails > is needed everywhere. If I get efficiency “for free” in just using > update > instead of checkout, that’s certainly the path I would prefer. > > But thanks for your suggestion anyway! I set up a system similar to the vendor/rails tip for the actual source of an app for a client. It’s checked out to the deployment machines once, and only updated from then on as there’s a lot of source which is uploaded over a pretty slow adsl line. I wouldn’t do it in all cases, but it made sense here. Chris ---
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 21, 2006, 11:11pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/6 "2006-05-21T23:11:48Z")
Al Evans \ writes: > manually might be just as easy. > Good point. It’s even easier, as I noticed when looking closer at > Capistrano: > There is already a remote:update\_current task labelled “Update the > currently > released version of the software directly via an SCM update operation”. > It’s not > documented in the manual so I missed it the first time. Thanks a lot for your reply! –Thomas ---
**Author:** ![wet](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/848f3c/32.png) [@wet](https://www.ruby-forum.com/u/wet)\ **Post date:** [May 21, 2006, 4:41pm UTC](https://www.ruby-forum.com/t/capistrano-update-instead-of-checkout/61053/7 "2006-05-21T16:41:55Z")
This might help, I didn’t want to store a rails version in svn or to make my deployment dependent on the rails site being up. Therefore, I checked out rails 1.1.1, and created a directory called rel\_1-1-1 under my home directory. Then I created this simple task below to create a symlink whenever it is deploying. I placed this code into the deploy.rb file. desc “Symlink Rails to version 1.1” task :after\_symlink, :roles =\> :web do run “ln -s ~/rails/rel\_1-1-1/ #{release\_path}/vendor/rails” end You would need to remove rails from your svn setup. Also, if you deploy 5 times and don’t clean out the old ones then you are using 200MB of disk space. With this method you would only be using a fraction of that amount of space, and it will finish much quicker! Hope this helps!