Subversion 1.4.5, Cap errors and work around.

[dacat]

I started a thread here => http://groups.google.com/group/capistrano/browse_thread/thread/81e3d5aa5d483575
that talked about how I was getting errors with Cap and deployment
from subversion via https. Well through more testing it appears to be
an issue with subversion 1.4.5

I have two hosts, on is running Svn 1.3 and is labeled DEV_HOST and
the other is running Svn 1.4.5 and is labeled PROD_HOST. On each host
I removed the the ~/.subversion directory to make it as homogeneous as
possible.

Below is the output from each host while running deploy:cold. You
will notice that the "production" stage immediately returns the
password prompt as and error but the "staging" stage displays it
normally and prompts for the acceptance of the certificate then the
password for the repository.

Now if i manually run the svn checkout command as cap does on
PROD_HOST (svn 1.4.5) it prompts for acceptance of the certificate
then password then checkouts the app with no issue. If I run
deploy:cold for the "production" stage after I ran the svn checkout
manually, deploy:cold runs with no error.

It's a kludge but it appears to work fine.

Note: PROD_HOST hosts the subversion server and all Cap commands were
run from DEV_HOST

--- output---
cap deploy:cold STAGE=production
* executing `deploy:cold'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
* executing "svn checkout -q -r117 https://PROD_HOST/repos/Projects/depot/trunk
/u/apps/depot/releases/20071010163218 && (echo 117 > /u/apps/depot/
releases/20071010163218/REVISION)"
servers: ["PROD_HOST"]
Password:
[PROD_HOST] executing command
** [err] Error validating server certificate for 'https://PROD_HOST:
443':
** - The certificate is not issued by a trusted authority. Use the
** fingerprint to validate the certificate manually!
** Certificate information:
** - Hostname: PROD_HOST
** - Valid: from Sep 6 19:23:46 2006 GMT until Sep 3 19:23:46 2016
GMT
** - Issuer: DELETED
** - Fingerprint: DELETED
** (R)eject, accept (t)emporarily or accept (p)ermanently?
** [err] Authentication realm: <https://PROD_HOST:443> Subversion
repository
** [err] Password for 'dacat':
** [err] Authentication realm: <https://PROD_HOST:443> Subversion
repository
** [err] Username:

cap deploy:cold STAGE=staging
* executing `deploy:cold'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
Error validating server certificate for 'https://PROD_HOST:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: PROD_HOST
- Valid: from Sep 6 19:23:46 2006 GMT until Sep 3 19:23:46 2016 GMT
- Issuer: DELETED
- Fingerprint: DELETED
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: <https://PROD_HOST:443> Subversion repository
Password for 'dacat':
* executing "svn checkout -q -r117 https://PROD_HOST/repos/Projects/depot/trunk
/u/apps/depot/releases/20071010163439 && (echo 117 > /u/apps/depot/
releases/20071010163439/REVISION)"
servers: ["DEV_HOST"]
Password:

[mflo...@gmail.com]

I was getting the same error, but found once I checked out manually, I
could deploy with only "cap deploy" - no cold deploy needed.

-Mario

On Oct 10, 1:01 pm, dacat <fda...@gmail.com> wrote:
> I started a thread here =>http://groups.google.com/group/capistrano/browse_thread/thread/81e3d5...

> * executing "svn checkout -q -r117https://PROD_HOST/repos/Projects/depot/trunk

> * executing "svn checkout -q -r117https://PROD_HOST/repos/Projects/depot/trunk

[wowo08]

Hi,
I had the same problem, but I found this solution:

just add the following line:

default_run_options[:pty] = true

here you can find the explanation from Jamis Buck himself:
http://groups.google.com/group/capistrano/browse_thread/thread/13b029f75b61c09d

For me it works now, how it should.

Best wishes,
Roman

On 10 Okt., 19:01, dacat <fda...@gmail.com> wrote:
> I started a thread here =>http://groups.google.com/group/capistrano/browse_thread/thread/81e3d5...

> * executing "svn checkout -q -r117https://PROD_HOST/repos/Projects/depot/trunk

> * executing "svn checkout -q -r117https://PROD_HOST/repos/Projects/depot/trunk

[Scott]

Mario,

I also fixed this by doing a manual svn checkout from the webserver:

svn checkout -q -r32 http://208.000.000.000/svn/garden /var/www/
mygardenplans.com/releases/20071102142631 && (echo 32 > /var/www/
mygardenplans.com/releases/20071102142631/REVISION)

When running the svn checkout manually, I noticed that it was asking
me for the 'root' password, but I don't have a svn 'root' user. After
typing a bugus password for root, I was asked for a username then a
password for the new username. In summary, it appears that latest
release of Capistrano ignores the :svn_username and :svn_password
values in the deploy.rb file. This forces svn to use the cached/
default username.

I didn't try the other work abounds mentioned in this thread, but it
sounds like they work as well. Take your pick.

-Scott

[Jamis Buck]

Since cap 2.0, Capistrano uses :scm_username and :scm_password,
instead of :svn_*. This way all SCM modules can use the same
variables, instead of inventing their own.

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-
> unsub...@googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>