UPDATED entire question to clarify things.
Software
Team Foundation Server 2010.
Background
Some while ago we migrated our Team Project Collection (= TPC) using Microsoft Team Foundation Server Integration Tools to a new TPC. We wanted to keep our build definitions as well, so we created a new build controller for the new TPC and then manually migrated the build definitions since the tool didn’t support that functionality. Once we recreated the build controller, the BuildID was reset. This behavior is understandable since each TPC has its own database where the unique BuildIDs are generated.
The problem is that our assembly versioning scheme uses the BuildID to make sure we can trace an assembly to the related build from TFS. This is why continuing the old BuildIDs (or manually configuring the next BuildID) is essential.
The question
Question is if there’s a setting by which we can define the range of the BuildID so that there’s no overlap with previous builds made by the deprecated Build Controller. For example, if in the old TPC, the last build was ‘499’, then we would like to set the range of the BuildID in the new TPC to [500-99999]”.
There are two ways you can solve this problem. The simplest one would be to modify the build workflow, and add an offset to the build id. You can expose the offset as an argument and add it to the metadata, so that it can be modified externally, or you could make it a fixed constant inside the XAML.
A more intrusive solution would be to modify the database directly. In the project collection’s database (e.g. Tfs_DefaultCollection), go to the tbl_Build table. The table’s primary key is the BuildId. It is an Identity field. All you need to do is change the seed to a new value (e.g. 500); The next build will have the modified build id.
I tried this on my own database, with no observable problems. I suggest you back up your TPC before trying it, just to be safe.
And suggest you simply modify the build to take an offset to the build id.
Hope this helps,
Assaf.