Here's my predicament.
TeamCity has been dutifully building a branch of our code. Our production release was tagged in both TeamCity (as well as pinned), and in Subversion. Our build generates a QA and a production binary. QA tested and approved the QA version of the release.
The branch was merged down to trunk. No worries. We have the tag.
Someone cleaned up TeamCity, deleting the branch config. It was cluttering up the Projects page. There's no way to globally hide a config, and thus this person thought ditching this branch config would be the best way to clean up the clutter. Unfortunately, a deleted config also deletes all the artifacts, including those that are pinned.
No worries. We have the tag.
Except that the build uses the svn revision number during one of the final phases (maven build). That revision number sets a version number within this installer file. That version number has to match another server side version number. If you check out a tagged version, you'll get the exact same source code, but the version number will be different.
We have the tag, but we have a problem.
TeamCity might allow the revision number to be part of the URL for subversion.
works just fine on the command line, as in
svn co https://ourserver/ourrepository/branches/BR_2.9/@7051 .
TeamCity objects to this URL. I wish it didn't.
We solved the problem here by releasing a new binary, but people are not happy.
We also won't be so quick to delete old configs.