github
Advanced Search
  • Home
  • Pricing and Signup
  • Explore GitHub
  • Blog
  • Login

vigetlabs / capistrano_rsync_with_remote_cache

  • Admin
  • Watch Unwatch
  • Fork
  • Your Fork
  • Pull Request
  • Download Source
    • 26
    • 5
  • Source
  • Commits
  • Network (5)
  • Issues (1)
  • Downloads (6)
  • Wiki (1)
  • Graphs
  • Branch: master

click here to add a description

click here to add a homepage

  • Branches (1)
    • master ✓
  • Tags (6)
    • v2.3.6
    • v2.3.5
    • v2.3.4
    • v2.3.3
    • v2.3.2
    • v2.3.1
Sending Request…
Enable Donations

Pledgie Donations

Once activated, we'll place the following badge in your repository's detail box:
Pledgie_example
This service is courtesy of Pledgie.

A deployment strategy for Capistrano 2.0 which combines rsync with a remote cache, allowing fast deployments from SCM servers behind firewalls. — Read more

  cancel

  cancel
  • Private
  • Read-Only
  • HTTP Read-Only

This URL has Read+Write access

yard hints 
mcornick (author)
Wed Sep 09 08:55:14 -0700 2009
commit  d9a8f91472d42f39c4c9763fceeb0459448a1b2e
tree    c0779aceace170e42b1548069933dd8f03d5533c
parent  d01bb37b28a61812866c6843a362153378c2329a
capistrano_rsync_with_remote_cache /
name age
history
message
file .document Tue Sep 08 08:12:49 -0700 2009 fix yardoc [mcornick]
file .gitignore Thu Aug 06 14:52:43 -0700 2009 Rakefile update [mcornick]
file LICENSE Wed May 13 15:37:29 -0700 2009 add Jeweler and most of a test suite [mcornick]
file README.md Thu Aug 20 12:20:16 -0700 2009 convert to markdown [mcornick]
file Rakefile Thu Aug 20 12:06:15 -0700 2009 Rakefile updates from new jeweler [mcornick]
file VERSION Tue Sep 08 07:50:50 -0700 2009 Version bump to 2.3.6 [mcornick]
file capistrano_rsync_with_remote_cache.gemspec Tue Sep 08 07:50:55 -0700 2009 Regenerated gemspec for version 2.3.6 [mcornick]
directory lib/ Wed Sep 09 08:55:14 -0700 2009 yard hints [mcornick]
directory test/ Tue Sep 08 07:50:34 -0700 2009 respect ssh_options[:port] in rsync; closes #2 [mcornick]
README.md

Capistrano rsync_with_remote_cache

This gem provides a deployment strategy for Capistrano which combines rsync with a remote cache, allowing fast deployments from Subversion repositories behind firewalls.

Requirements

This gem requires Capistrano 2.0.0 or higher. Git support requires Capistrano 2.1.0 or higher.

This gem supports Subversion, Git, Mercurial and Bazaar. Only Subversion and Git have been extensively tested. This gem is unlikely to be supported for other SCM systems.

This gem requires rsync command line utilities on the local and remote hosts. It also requires either svn, git, hg or bzr on the local host, but not the remote host.

This gem is tested on Mac OS X and Linux. Windows is not tested or supported.

Using the strategy

To use this deployment strategy, add this line to your deploy.rb file:

set :deploy_via, :rsync_with_remote_cache

How it works

This strategy maintains two cache directories:

  • The local cache directory is a checkout from the SCM repository. The local cache directory is specified with the local_cache variable in the configuration. If not specified, it will default to .rsync_cache in the same directory as the Capfile.
  • The remote cache directory is an rsync copy of the local cache directory. The remote cache directory is specified with the repository_cache variable in the configuration (this name comes from the remote_cache strategy that ships with Capistrano, and has been maintained for compatibility.) If not specified, it will default to shared/cached-copy (again, for compatibility with remote_cache.)

Deployment happens in three major steps. First, the local cache directory is processed. There are three possibilities:

  • If the local cache does not exist, it is created with a checkout of the revision to be deployed.
  • If the local cache exists and matches the :repository variable, it is updated to the revision to be deployed.
  • If the local cache exists and does not match the :repository variable, the local cache is purged and recreated with a checkout of the revision to be deployed.

Second, rsync runs on the local side to sync the remote cache to the local cache. When the rsync is complete, the remote cache should be an exact replica of the local cache.

Finally, a copy of the remote cache is made in the appropriate release directory. The end result is the same as if the code had been checked out directly on the remote server, as in the default strategy.

Blog | Support | Training | Contact | API | Status | Twitter | Help | Security
© 2010 GitHub Inc. All rights reserved. | Terms of Service | Privacy Policy
Powered by the Dedicated Servers and
Cloud Computing of Rackspace Hosting®
Dedicated Server