hello,
I used capistrano with cvs reposity... and I think that cvs.rb is bugged...
In fact, Capistrano try to execute cvs -Q -d [EMAIL PROTECTED]:/var/lib/cvs
checkout -r 2008-05-16 09:53:03 +0200 -d 20080516122636 toto
buts it's not possible to execute that because
-r = is a revision, not
Hey Julien,
I think Jamis would welcome a patch because my guess is there is not many
people that can help with this. Most switched from CVS already.
When you make a patch, don't forget to update tests or create new ones.
Also, test your patched version with CVS as much as you can, and include
Thanks for reply.
Here it is:
#
[EMAIL PROTECTED]:~$ git --version
git version 1.5.2.5
#
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
Hi all,
I'm looking into using Capistrano for system administration as opposed
to deployment. I'm having some trouble handling errors.
As an example, I'm trying to write an add_user task. Easy enough:
task :add_user do
run useradd #{username}
end
The problem is in handling error
Yeah, I think it was called 'subproject' until 1.5.3, and was pretty
experimental at that time. The easiest thing would most likely be to
upgrade to 1.5.3 or newer on the release machine.
On Tue, May 20, 2008 at 3:30 AM, Aurels [EMAIL PROTECTED] wrote:
Thanks for reply.
Here it is:
#
Strange, I had the opposite effect. I upgraded to 2.3.0, and now I
have to enter my sudo password. I have the following in my sudoers
file:
dave ALL = NOPASSWD: /usr/local/bin/god
dave is the user I'm using for this example. Run sudo god status on
the remote box, and there is no prompt for a
I (hardly) compiled version 1.5.5.1 and it seems to work!!
Thanks a lot for your help.
Any ideas when this feature will be propagated to official packages
for linux distros? Is it still experimental?
--~--~-~--~~~---~--~~
To unsubscribe from this group, send
This ticket (http://capistrano.lighthouseapp.com/projects/8716/tickets/
5) was opened a couple weeks ago because of this same issue, where
someone wants capistrano to ask the remote host what the revision is,
rather than the local host. Feel free to post your comments there;
perhaps an idea
Hmm..I guess the question is: Which use of sudo is the more common/legitimate case - the case where all commands are available via sudo or the case where the set of commands is limited? I used to think the latter until I got my Mac a couple months back and discovered that I have sudo
As I responded to someone else in another topic: this is totally my
bad. I'll be reverting this in the next release, but it means that
deploy:setup (which finally uses sudo in 2.3) will have to revert to
non-sudo in the next release unless someone has a good idea of how to
make something
Ah, oops, err, pardon me for not posting everything I had tried, but
alas, :on_error does not do the trick here. The current version is:
task :add_user, :on_error = :continue do
prompt(:username)
#prompt(:new_password)
begin
run useradd #{username}
rescue Exception =
Honestly, I think I'd recommend just removing the server in question
from the server list temporarily, running your stuff, and then adding
it back. I might consider a patch to capistrano to work around this,
but at the same time, capistrano is already ridiculously complex in
places.
-
This could be ugly, but when Cap is presented with "sudo x y", could that actually be executed as "sudo x sudo y"?I haven't tested it and have no idea if it would work with regard to both running both commands successfully and returning the correct values for success/failure on the
The real sticky one this when you're using conditionals or something,
e.g.
if [ -x /path/to/something ]; then cd /path/to; something; fi
First of all, you can't do sudo if [...] ... fi, because if isn't
a command, it's shell syntax. You either need to do sudo sh -e '...'
or you do if
I'm not sure yet whether that's a pattern or an antipattern. If it's a
pattern, then maybe we could do something like:
HOSTS=-foo
to remove host foo from whatever the normal host list would be?
On Tue, May 20, 2008 at 3:03 PM, Jamis Buck [EMAIL PROTECTED] wrote:
Honestly, I think I'd
Well, one possibility would be to try to parse everything, and be smart:
if sudo [ -x /path/to/something ]; then cd /path/to; sudo something; fi
Yes, /usr/bin/[ does exist, at least for me. But this way lies madness --
that 'cd' obviously must be run in some kind of shell to affect the
following
It's an exception. If it pains someone enough to write a patch for it,
I'd consider applying it, if it doesn't do unnatural things to the code.
- Jamis
On May 20, 2008, at 4:16 PM, David Masover wrote:
I'm not sure yet whether that's a pattern or an antipattern. If it's
a pattern, then
I like the SQL placeholder comparison. That might be a more sane
approach than some of the options I've been considering.
- Jamis
On May 20, 2008, at 4:36 PM, David Masover wrote:
Well, one possibility would be to try to parse everything, and be
smart:
if sudo [ -x /path/to/something ];
18 matches
Mail list logo
