Currently I have an local netwerk containing my development
environment.
This includes the computer I am running Capistrano on and an Apache-
svn server.
On my test server the repository is reachable and Capistrano works
perfect.
I would like to be able to run Capistrano to setup my live
Sorry, wrong Information. It isn't working on this machine after
adding the ssh_options[:paranoid] = false option.
just the add_key method works. I was remote on the wrong box as i
tested again.
after entering my password i get an SocketError.
Full error here:
http://pastie.caboo.se/59791
On 8
Doing the things described here won't fix the problem.
http://rubyforge.org/forum/forum.php?thread_id=13883forum_id=1177
Is it a problem with Capistrano or net-ssh?
is Capistrano using an different implementation?
On 8 Mai, 10:18, dweinand [EMAIL PROTECTED] wrote:
Sorry, wrong Information. It
Hi,
Could you try the suggestion I've just made in that thread?
I believe you should also be able to fix this problem without editing your
services file, by changing line 108 of net/ssh/transport/session.rb to:
ip_address = Socket.getnameinfo(addr, Socket::NI_NUMERICHOST |
Thank you, just found your Thread and wanted to tell it here. But
you've been faster.
Thank you for the fix. Works now on this machine.
Great Work!
On May 8, 12:16 pm, Chris Andrews [EMAIL PROTECTED] wrote:
Hi,
Could you try the suggestion I've just made in that thread?
I believe you
Ah, thanks for testing that out. This getnameinfo issue on Windows seems to
be causing a few problems that have been reported here, and this seems a
reasonable fix -- it doesn't cause trouble on either OSX or Linux.
Chris.
On 08/05/07, dweinand [EMAIL PROTECTED] wrote:
Thank you, just found
Hello,
i'm just looking for a solution to rollback my app after a migration
failed.
I'd like to run the migration with every deploy command. but if the
migration fails, i'd like to rollback to the last version before the
migration.
can i do a dry run to check if the migration is ok? or do i
I'm not sure I understand what you mean by reverse tunnel.
Is the problem that your production environment cannot access your
subversion repository? If so, then the solution is in Capistrano 2.0,
where you can say:
set :deploy_via, :copy
And deployments will then do a local checkout,
thats one of the things I love about postgresql, you can wrap
migrations in a transaction, so failed migrations leave the database
in a determinable state.
coupled with this plugin, it makes life easier...
http://www.redhillonrails.org/#transactional_migrations
However (at least with cap 1) if
Agreed. OSX has the same problem and ssh_options[:paranoid] = false
works around it.
Casey
On May 2, 9:24 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I'm also remote deploying from OS X.
Adding ssh_options[:paranoid] = false does solve the problem.
Looking through the 1.0.10 docs, it
As a way of managing my sanity while keeping Capistrano 1 and 2
installed for different projects, I created a few Bash aliases to make
the process more obvious. My cap wrapper script is installed in /
opt/local/bin/cap, and I've setup the following:
alias cap='echo You must run either cap1 or
This has been fixed in http://dev.rubyonrails.org/changeset/6702. It
will be part of Preview Release 2, later this week.
The above change implements the following:
1. If you set neither :scm_command nor :local_scm_command, the
default will be used for both local and remote hosts.
2. If you
12 matches
Mail list logo
