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]:XXXXXXXX@our.svn.server'
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?
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?