* [#TeamCity Backup issues]
* [#Per build configuration, shareable VCS Roots]
* [#Visual Studio pre-tested commit support for Subversion]
* [#StarTeam Support]
* [#Show build start/stop time estimations in the build queue]
* [#Possibility to assign agent to specific build configurations only]
* [#UI improvements]
* [#Detection of hanged builds]
* [#Other issues]

h2. TeamCity Backup issues

Before upgrading to TeamCity Benares, please [back up|TCD3:TeamCity Data Backup] your data. The table below will help to determine which information to back up.
*$TEAMCITY_DATA_PATH* references the location of TeamCity's data files, by default this location is [$HOME/.BuildServer|http://www.jetbrains.net/confluence/display/TCD3/Basic+Concepts#BasicConcepts-dd].
|| Stored information || Form || Location || Backup required ||
| Project and build configuration settings, authentication scheme, database configuration | files | *$TEAMCITY_DATA_PATH*/config, *$TEAMCITY_DATA_PATH*/system/version.dat | (/) |
| License | files | *$TEAMCITY_DATA_PATH*/system/license.keys | (/) |
| User accounts, Build history | database | *$TEAMCITY_DATA_PATH*/system/buildserver.\* for HSQLDB, or Mysql dump | (/) |
| Build artifacts | files | *$TEAMCITY_DATA_PATH*/system/artifacts/\* | optional |
| Build logs | files | *$TEAMCITY_DATA_PATH*/system/messages/\* | optional |
| Personal builds info | files | *$TEAMCITY_DATA_PATH*/system/changes/\* | optional |
Items marked *Backup required* are essential for restoring TeamCity to its previous state. As you can see, you can skip build logs and artifacts (these files are not affected by the upgrade).

h2. Per build configuration, shareable VCS Roots
{jiraissue:key=TW-792}
Benares allows you to have different VCS root settings for different build configurations of a single project. So, now you can have build configurations for different branches and different VCS settings within a single project.

Moreover, you can share VCS roots between several projects, so if you have a shared library you can have one place to edit VCS settings for this library.

You still can use several VCS roots in a single build configuration, and in Benares you can also specify the include/exclude rules for a particular VCS root. You can also map some of directories in VCS to directories in the target source tree.
!vcsRoots.png! !checkoutRules.png!

h2. Visual Studio pre-tested commit support for Subversion
Now you can employ TeamCity pre-tested commit functionality from Microsoft Visual Studio 2005 not only for sources controlled by Team Foundation Server, but for Subversion-controlled sources too.
!vs-subversion.png!

h2. StarTeam Support
Initial support for StarTeam version control system has been implemented.
Supported version are from 5.2 and up.

To use StarTeam sources roots, StarTeam SDK should be installed on the TeamCity server and starteamXX.jar (usually placed in "c:\Program Files\Borland\StarTeam SDK NN\Lib\starteamNN.jar" ) should be copied into <TeamCity home>/webapps/root/WEB-INF/lib directory.
Please also ensure TeamCity server and StarTeam server are time-synchronized.

Known Issues
# Pre-tested commit isn't yet supported;
# Deleted files are reported as changes by anonymous user;
# Renamed files are reported as remove+modify, not remove+add;
# Modification to items' properties (not related to item's content)are detected as changes by TeamCity.

h2. Show build start/stop time estimations in the build queue
{jiraissue:key=TW-95}
!Screenshot.png!

h2. Possibility to assign agent to specific build configurations only
{jiraissue:key=TW-314}
Normally, a build agent's system properties and environment variables are defined, and then you specify requirements for the build agent in build configuration settings. This allows you to run windows-specific builds on windows build agents and to run builds which require WebLogic only on build agents that have WebLogic installed.

If a build configuration doesn't have specific requirements, it can run on any available build agent.

Sometimes, however,&nbsp; this isn't desirable behaviour. You may want to have a build agent, which only runs one (or two) specific build configurations, even if there are a number of build configurations compatible with the build agent . This is now possible with the new run configuration policy:

!1.png!

h2. UI improvements

First of all width of TeamCity UI is not limited to 1024px anymore. It will take as much space as your screen allows. Next, quick links popup is replaced with tabs on build configuration home page. Note that there is a "Settings" tab. On this tab you can review build configuration settings and navigate to corresponding section of build configuration in Administration zone. There is also "Edit Configuration Settings" popup for faster navigating to administer various aspects of build configuration.

!buildtype.png!

On a build page tabs are moved to the left side. More details are shown for elapsed / estimated time of a build.

!build.png!

On the server configuration settings page you can now review where TeamCity stores its data:

!settings.png!

h2. Detection of hanged builds

TeamCity now applies a number of heuristics to detect hanged builds and to send notifications about such builds. You can opt in for the notification on the notifier settings pages.

h2. Other issues

* Persist information about what triggered a build {jiraissue:key=TW-399}
* Support for Tomcat 6.0: TeamCity .exe and .tar.gz distributions are now bundled with Tomcat 6.0 {jiraissue:key=TW-2248}
* Possibility to disable authentication for artifacts repository {jiraissue:key=TW-2836}
* Possibility to read build properties and environment variables from a file {jiraissue:key=TW-2991}
* .NET agent plugin now detects .NET Framework 3.5 and defines necessary properties. See [corresponding documentation page|TCD3:System Properties of a Build Configuration#Agent-specific] for more. {jiraissue:key=TW-2999}