Browse files

Altered the `ls` command used to list older releases, should fix #88

…for the majority of use cases; have documented the other options for people who need to customise this via the :release_name functionality.
  • Loading branch information...
1 parent 810f956 commit 92941e855d70a5778eb094a972fdf43c70802b95 @leehambley leehambley committed Dec 17, 2009
Showing with 2 additions and 1 deletion.
  1. +2 −1 lib/capistrano/recipes/deploy.rb
3 lib/capistrano/recipes/deploy.rb
@@ -38,6 +38,7 @@ def _cset(name, *args, &block)
_cset(:strategy) {, self) }
+# If overriding release name, please also select an appropriate setting for :releases below.
_cset(:release_name) { set :deploy_timestamped, true;"%Y%m%d%H%M%S") }
_cset :version_dir, "releases"
@@ -50,7 +51,7 @@ def _cset(name, *args, &block)
_cset(:current_path) { File.join(deploy_to, current_dir) }
_cset(:release_path) { File.join(releases_path, release_name) }
-_cset(:releases) { capture("ls -xt #{releases_path}").split.reverse }
+_cset(:releases) { capture("ls -x #{releases_path}").split.reverse }
_cset(:current_release) { File.join(releases_path, releases.last) }
_cset(:previous_release) { releases.length > 1 ? File.join(releases_path, releases[-2]) : nil }

6 comments on commit 92941e8


This change seems to cause breakage; at least, what we were seeing is that Capistrano started running db:migrate commands out of a previous release instead of the release that was being deployed.


Same problem here. Not using any custom release name.

On my last deploy I observed that the current_release was pointing to the oldest release in the releases directory. I worked around it by changing current_release to latest_release wherever I used it in my own code.

current_release is also used in db:migrate and deploy:cleanup. When I ran deploy:cleanup, it removed all but the oldest 5 releases!



Either :releases has to be in reverse chronological order (as you would get when sorting with "ls -t" and reversing) or :current_release needs to take the first (and :previous_release the second) entry.

I'm guessing the intention was to change from using ls lexicographical sort to using directory timestamps. (Perhaps covering the case where directories are not named after timestamps?) Seems reasonable, but the "reverse" needs to be taken out, since -t lists most recent first, and lexicographical sort will yield most recent last.


+1 It took a while to see that capistrano, and not my git repo or server, was causing weird errors like "no such file as config/boot" and "no such file as config/database.yml". Reverting to from 2.5.11 back to 2.5.10 fixed this issue.


(that was +1 for the comments about issues, not the commit)

Capistrano member

Fixed in the latest release (hit gemcutter an hour ago) also Kieran, this isnt' really a monitored forum, please use the appropriate places (google groups, and lighthouse app)

Please sign in to comment.