command line Error: Unable to connect to a repository at URL

ddorval

I finally got migration scripts to work from the command line but after moving the updated command to the build script it fails on the build machine.

I copied the actual sqlcompare command used from the log and replaced the local paths with network paths (so I'd be reusing the same folders/files) except for /scriptfile and it worked fine. I then cleared the Authentication Data in Tortoise SVN and now I get the same error running from my machine.

I am specifying the following switches:
/scripts1:"local database folder of branch being built"
/scripts2:"local database folder of Trunk"
/scriptfile:"file name/path of output"
/options:Default,IgnoreTSQLT
/force
/migrationsfolder:"local migration folder of branch"
/scriptsfolderxml:"local file with contents from db extended property"
/revision1:"revision number of branch"
/revision2:"revision number of trunk"
/versionusername1:"username"
/versionpassword1:"password"
/versionusername2:"username"
/versionpassword2:"password"

I've verified the username and password are correct. svn info with the url from the error and the username and password specified works.

Our build system actually copies the branch being build to a new branch with the build number then gets that branch for the build. To save having to maintain the /scriptsfolderxml file I thought I could be clever and update that file as part of the build with the url of the build branch. Doing this didn't give an Error but also didn't use the migration scripts .

It would also be nice to not have to specify the /scriptsfolderxml since that url is also in the migrationScript file.

Brian Donahue

If SVN is configured to use Windows Authentication, it doesn't seem to matter what you use for the versionusername/password. If you have "enterprise" (paid-for) SVN server, you will want to check the logs to see who you are actually logging in as.

With Windows Auth, I am guessing Windows transparently logs in as the user running the command, because I can change these options to invalid users and passwords, and it still works.

If you are using the SVN authentication database, please let me know and I'll forward this support query on to someone who can help.

ddorval

I'm not sure how we have SVN configured. I know we use our network credentials to login to svn but we do have to actually login. Our build server is not on the domain anyway so I do not think it is using Windows Authentication. As a work around I created a console application that uses sharpsvn to do an svn info command and cache the credentials. Adding that to the msbuild script before the call to sqlcompare allows sqlcompare to work.

I don't know all the details about how all the different svn's work but when testing at the command line all I had to do was call svn info and then sqlcompare would work but when running inside an msbuild script svn info wasn't enough and I had to write a program to use sharpsvn.

Brian Donahue

I guess you need to grant access to SVN for whatever user is running MSBUILD or get that process to impersonate another user that has access. I don't know enough about your setup to say how you would go about that.

ddorval

I am using svn credentials that have access, that's why it works once the credentials are cached. It would be nice to be able to specify the credentials to use for svn when connecting for migration scripts. SVN isn't using Windows Authentication.

Brian Donahue

Nobody has provided me with an answer to this question, but as far as I can tell from looking at the source code, the SVN credentials are always got from the SharpSVN API. The SQL Source Control code is invoked to bind to SVN and that code only seems to retrieve cached credentials, and if none are present, it should show a prompt. It seems to remember the last username, though, so possibly the username command-line option will get it to connect as the right user.

So something between SQL Compare and SQL Source Control seems to have broken down. But I could be misunderstanding the code. I can't get a comment in-house from anyone as to what is going on.

In the meantime, I suppose making a connection to SVN using SQL Source Control should repopulate the cache and that may fix the problem.

ddorval

As a work around I wrote a command line application that also uses SharpSVN to connect to svn with the sole purpose of caching the credentials for sqlcompare. We are running sqlcompare.exe from within an msbuild script being executed using the msbuild api objects (not msbuild.exe) within a .net Windows Service...so there is many layers of no UI.