You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 5, 2020. It is now read-only.
I have been experimenting with and evaluating this tool for use at the company I work for and have run into a pretty major bug that seems to have been mentioned a few times before (issue 337, 710), but still seems to be lurking. The remote environment I am deploying to has Subversion client v1.7 installed, and everything works fine when deploying there. Recently, I decided to set up a local deployment configuration on my Vagrant vm which has Subversion client v1.9 installed. When I attempt to deploy to this environment, during the clone step, the svn checkout command fails. I receive the following error message:
/usr/bin/svn co https://[username]:[url_encoded_password]@our.svn.server/path/to/repo/trunk /path/to/destination --non-interactive --username="[username]" --password="[password]"
An error occured: "Unable to clone the repository", while running:
svn: E170000: 'https://[username]:[url_encoded_password]@our.svn.server/path/to/repo/trunk' isn't in the same repository as 'https://[username]:[email protected]'
I rolled back my svn client version on vagrant to 1.8 and received the same error. I then rolled it back to 1.7 to match our remote servers, and everything works as expected. As a test, I installed Subversion client 1.9 again, manually ran the checkout command exactly as it appears above and of course received the same error message. I then removed the username and password from the url, but kept the --username and --password options, and the command completed successfully. I read through the Subversion change logs and didn't see any obvious changes related to authentication that I could relate to this error. Unfortunately, I don't have the option of using a different authentication method or downgrading the Subversion client on my vagrant machine to fix this error, so we are at a complete roadblock.
Is there a reason that the checkout command includes the username and password in both the url and the command options? Could this be re-worked into a configurable option?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have been experimenting with and evaluating this tool for use at the company I work for and have run into a pretty major bug that seems to have been mentioned a few times before (issue 337, 710), but still seems to be lurking. The remote environment I am deploying to has Subversion client v1.7 installed, and everything works fine when deploying there. Recently, I decided to set up a local deployment configuration on my Vagrant vm which has Subversion client v1.9 installed. When I attempt to deploy to this environment, during the clone step, the svn checkout command fails. I receive the following error message:
I rolled back my svn client version on vagrant to 1.8 and received the same error. I then rolled it back to 1.7 to match our remote servers, and everything works as expected. As a test, I installed Subversion client 1.9 again, manually ran the checkout command exactly as it appears above and of course received the same error message. I then removed the username and password from the url, but kept the --username and --password options, and the command completed successfully. I read through the Subversion change logs and didn't see any obvious changes related to authentication that I could relate to this error. Unfortunately, I don't have the option of using a different authentication method or downgrading the Subversion client on my vagrant machine to fix this error, so we are at a complete roadblock.
Is there a reason that the checkout command includes the username and password in both the url and the command options? Could this be re-worked into a configurable option?
The text was updated successfully, but these errors were encountered: