Please disable the "Overwrite Package" permission in Admin > Tasks. Then, you will get "Package Already Exists" error

This will be added as an Operation in the next release; look for [BM-2218]. IUn the mean time, the legacy action is a good work-around.

Alright, v5.1.2 was released and it should be correct now :)

Note this response will be handled via an email chain and will require either a new SVN extension or require a change to BuildMaster to resolve. Also see the following thread on GitHub: https://github.com/Inedo/bmx-subversion/issues/9

For completeness, this specific issue was related to invalid credentials, in this case, the username was being entered with a domain prefix when the SVN server did not require one.

It does not, it will require a custom action or script. If you can output the current revision to a file, you can use the "Set Variable From File" action to something like $SvnRevision, then reference that later in your build/deployment plan.

I've figured out what I would like to see and its an approach I've seen other tools take. I think you need a BuildMaster plugin for Jenkins that I can add as a build step in Jenkins to: Import ReleaseNumber as a variable Trigger a BuildMaster Job and a) send selected artifacts to BuildMaster, b) set the BM build number to the Jenkins build number (I just like to keep things in sync for traceability) Workflow SVN Commit -> Jenkins Build -> BuildMaster: Import Sent Files I'd then deploy to first environment (using the BM post build step action) which would do the deployment and then call test job in Jenkins to verify deployment and/or perform regression testing. I've got most of this working using groovy scripts, but it would certainly improve things if wrapped in a plugin.

Fixed! The issue was that the subversion configuration was pointing to its local svn.exe instead of the one we had installed on the server. I had to change the 'Path to svn client' field to point to our copy of svn.exe. Thanks again.

It wasn't clear to me, from the UI, that I should be selecting the path to the solution file, rather than to the project. When I selected the solution file, the recipe proceeded to create a couple of problematic actions - "Subversion does not support the "Apply Label" operation. I think you're right - I'd be better served building up my deployments from scratch, rather than trying to use the recipes. The recipes seem to make assumptions that don't always fit, and it's easier to build your own than to figure out what they are doing that isn't working.

The extension bundles a version of svn.exe, and you can actually find it in and run it from the {BuildMasterInstallDir}\_WEBTMP\ExtTemp\Subversion\Resources\ directory. The command that it runs to validate a connection to a SVN repo is: svn.exe info http://inedo-test-project.googlecode.com/svn/trunk --xml --non-interactive --trust-server-cert [--username xxxx] [--password xxxx] Try that and see what happens when you run it.

Are you using the embedded/built-in SVN client, or are you pointing at your own svn.exe, and if so, what version is it? That behavior seems odd since BuildMaster explicitly instructs the command line client to ignore these types of errors: https://github.com/Inedo/bmx-subversion/blob/master/Subversion15Provider.cs#L318 As a workaround, I suppose you could run the command line under the same account that BuildMaster runs as and accept the certificate manually as you have likely done with your own account. If you need to accept the certificate as LOCAL SYSTEM, you can follow the steps here under Using LOCALSYSTEM Windows Service to accept it as LOCAL SYSTEM. It's also worth noting that for the non-interactive/trust-server-cert flags to be acknowledged, the hostname of the SSL certificate installed on the server must be the same as the one in the repo URL. Is it possible that your SVN server cert is assigned to an IP address instead of the hostname, or vice-versa perhaps?

Hello David! You can add multiple repositories like that in the "Repositories" section when editing the source control provider. When you're editing the provider, enter: http://myserver/svn/ as the Subversion URL, and the repos would be: Relative Repository Path: Repo1 Repository Name: Repo1 If you're having trouble with that, you could always just add multiple source control providers each with their Repository URLs pointing at their own repos.

Thanks, we will wait for the updated svn extension, and use the execute command line option in the mean time.

As it turns out this is a problem related specifically to the SVN extension and will require us to release a new version of the extension. We will have this out within the next few days. As a workaround, you can call the Execute Command Line action directly with the appropriate SVN checkout arguments in order to get the latest code.

Just to update anyone reading this. Having spoken to support I was being a bit of an idiot. When prompted to select from SVN (Step = Select Provider/File) it wants a file, not a folder. So /Project/ will error, but if you pick a file in that folder all works.

I'm getting the error with both the bundled client and with Collabnet's Subversion client. I'll into the credentials of the App Pool & Service.

Hi Jan, Subversion does not support the "Apply Label" operation, so it complains about this. The UI is supposed to prevent you from using this action, but I think one of the recipes will create this action for you. Just replace the Apply Label / Get Labeled action pair with: Tag /trunk/mypath to /tags/%RELNO%.%BLDNO% Get Latest from /tags/%RELNO%.%BLDNO% Hope that helps, Tod

Yes; just set up an Source Control Triggered Automatic Build ( http://inedo.com/support/documentation/buildmaster/core-concepts/builds/source-control-triggered-builds ) that watches the desired path(s), and a build will be kicked off when that changes.