I'm trying to apply Label on a file, but I obtain this error because Label already exists on an old version of file:
TF203007: Cannot create the label because the version controlled item $/MyProj/MyFile.cs already exists or has been specified more than once.
I want move Label from an old version to Latest.
Is it possible?
Thanks a lot!
A very easy workaround (if it's allowed in your case) to resolve this error mesg is (especially when everybody is standing behind you to fix this issue on urgent basis):
Just change the buildnumber.txt file (The file which holds the last successful buildnumber "number" in it) and bump the number to a new value i.e. if you are getting an error that TFS>. ... can't label ... file and during that build time the build label that TFS was trying to apply (lets say) is : TFS_RELEASE_BUILD_5, then, just bump the build number to 10 or 20 or 50, i.e. the next build number your build script will generate automatically will be either 11, 21 or 51.
Problem resolved.
My case:
I created a branch "11.0" sometime 2 weeks back. On this branch, we created builds from 1 to 10. Build label was in format: TUD_COR_11.0.0.1 ..to 10.
Yesterday, I deleted 11.0 branch.
Yesterday, we had to recreate this branch again from a new source branch so what we did was:
a. deleted 11.0 branch. checked in the change so branch is gone now.
b. Deleted all the builds that were created by the build defintion and finally deleted the build definition (as other team members wanted me to create a new build definition for the new 11.0 branch (to be created from a new source branch) again from scratch. While creating the build definitions, I successfully saw the "tick" marks against labels/etc/anything related to existing build definitions were going to delete as per the Delete operation.
Now I created new 11.0 branch again from latest data from the source branch as of today.
Created the build definitions again.
Created COR build again with build label TUD_COR_11.0.0.1. Now TFS gave me the similar "error mesg" as mentioned in the thread above.
Possible resolution:
A. Delete the file "as per the build log" where TFS Label operation is failing. You can use sidekick -OR TF label command. Note: This can be time consuming as what if you delete the label from the file (OR delete this file under this label i.e. this label is not applied to this label anymore).
*NOTE: Here we are NOT deleting the file from source control. just removing the file from the label concept
B. OR just increase the buildnumber.txt .. that the build script uses to generate the build label i.e. if my buildnumber.txt (which is somewhere in the source control branch tree), it contained a value of "0" and it was creating build "1" with label: TUD_COR_11.0.0.1 (where branch is 11.0 and build series is 11.0.0.1) i.e. ... format. Now if I just change the value of this buildnumber.txt to "10" (why as that was the last build number we successfully created when we HAD 11.0 branch earlier (before we deleted it).. so I bumped the buildnumber value to 10 i.e. now if I run the build definition again (i.e. queue the build), build script will generate a new build with number: 11 i.e. with build label "TUD_COR_11.0.0.11". Problem solved in few SECONDS here. Nobody in the company raised any doubts in doing this as this was a development branch so they didn't care what build number we(SCM team) are providing to them. They just wanted a successful build.
It sounds like it is trying to apply the label to a version of that file that already has that label. If you use tf label, it will move the label if it can, so you're doing that the right way.
One thing to check is whether the version in the workspace is the version that you want to label. Otherwise, specify the versionspec (e.g. the following will label the latest version of the file regardless of what you currently have in your workspace):
tf label "$/MyProj/MyFile.cs" /version:T /server:http://tfs:8080
If you could post the tf label command line you're using it might also help.
(edit: the tf command above would work for tfs 2005 and 2008. You'll need to specify the project collection instead of server for tfs 2010).
Related
I have a custom TFS Build template that includes a procedure that runs a process that involves getting some data from a server and checking it into TFS before moving onto the main build process.
The steps are as follows:
Set build number
Run our custom script - get data, check into TFS
Initialize environment
Get sources from Team Foundation Version Control
Associate the changesets that occurred since the last good build
Compile, Test and Publish
The issue I appear to be having is that all change sets since the last successful build are included, except, the change set associated with the script run at step 2.
Does anyone know what could be going on here? my guess is that the logic that is looking for the change sets since last build is using a cut off that is set at the moment the build is requested (hence why the last change set is ignored) but this is just an uneducated guess.
Thanks in advance for your help.
Trying the steps below:
Edit your build definition and go to "Process" tab.
Enter "T" under "Get version" option.
Queue the build and check the result.
I would have two builds chained: the first build generates and check-in the files the second simply pulls them down.
I have a TFS branch Main. I want to create a hotfix branch for MVCWebSite project.
My build definition for MVCWebSite applied a Label to MVCWebSite and the SharedClassLibrary only, I wasn't releasing the ConsoleApps so didn't need a Label for these.
\MvcMusicStore\Main\MySolution\ConsoleApp1
\MvcMusicStore\Main\MySolution\ConsoleApp2
\MvcMusicStore\Main\MySolution\MVCWebSite
\MvcMusicStore\Main\MySolution\SharedClassLibrary
\MvcMusicStore\Main\MySolution\Packages
\MvcMusicStore\Main\MySolution\BuildProcessTemplates
How can I create a HotFix for just the MVCWebSite?
I would not suggest making a branch only for the single project you need to branch the entire solution. You can use the changeset number instead of the label to get the appropriate version of the entire solution and then convert that into a branch. Steps:
Find the label you want
Open it and get the changeset number (screenshot below)
Get specific version based on changeset number
Convert to branch
We have our projects configured with MSBuild script customization to modify the ApplicationVersion property in the project and copy that into the AssemblyInfo.cs file when the project builds. The problem is that we have TFS set up to run on a nightly schedule, with "Build even if nothing has changed since the previous build" unchecked. But since TFS itself is producing this version update, it will rebuild and increment every night. So this is sort of an infinite loop of our own design, but trying to figure out how to get out of it.
If the "changed since the previous build" detection is based on the history timestamp, ideally it'd be nice if when the version gets updated and commits to TFS it does it with a timestamp that precedes the build time. Is that even possible?
If the "changed since the previous build" detection is based on some boolean/bit flag, is there a way to reset it?
Using TFS 2012.
I'm assuming that you're checking in the new version of the assemblyinfo.cs once it's been updated, and this is why TFS is queuing a new build. Have you tried adding a comment to the checkin of ***NO_CI*** This will definitely suppress a CI build but I'm not 100% certain if it will work in your scenario.
Another option is generating the version number via an algorithm rather then just incrementing a counter and checking it back in to Version Control. This circumvents the issue of a new build being triggered
i.e if your version number looks something like
1.2.3.4
Where 1 is Major (modified by a human not the build process)
2 is minor (also modified by a human)
the final 2 digits are then updated by an automated process.
You could use number of days since January 2000 for digit 3 (an arbitrary number but something that would change on a daily basis) and either the latest changeset number in Version Control or the total number of builds performed by TFS for digit 4.
This would fulfill 2 requirements, that version numbers are unique for a given build of an assembly, they always go up.
I would suggest that you don't check the new version number into TFS. There is no value in having the version number in there.
I typically set the checked in assembly info numbers to all zeros. ( 0.0.0.0) and never update them except locally for the build.
This gives you the benefit of always being able to identify locally built DLLs.
My team uses a per-release and per-sprint branching approach. So we typically have a fresh branch off of Main (integration) for the current sprint and a branch off of Main for each release.
Main Branch
|
-- Development Folder
| |
| -- Sprint 2.10_1 Branch
| -- Sprint 2.10_2 Branch *current*
|
-- Release Folder
| |
| -- Release 2.8.0 Branch
| -- Release 2.9.0 Branch *current*
There are two build definitions. One points at the current dev branch and the other points at the current release branch.
This setup is working well, except that it has become a bit time-consuming and error-prone to update all the branch paths in the builds every time we branch for a new sprint and branch for a new release. Each build has branch paths in these places:
Source Settings > source control folders (multiple active and cloaked paths)
Process parameters > Build > projects to build (paths to multiple
projects)
A build only ever points to one branch location in tfs, and the only part of that branch path that changes each time is the number associated with the current sprint or release. So for instance a build might switch from pointing from /developement/2.10_1/ to /developement/2.10_2/.
Is there a way to define a base-path once in your build definition and then use it throughout the definition? That way each time we switch branches we only have to specify the branch path in one place? Even better, could that variable's value be managed outside of the build definition so that it could be used by several build definitions? Could the variable value possibly be dynamic based on the active Iteration for the project?
Or can the path entries in the build definition be defined in such a way that they are relative to the branch?
Any suggestions? Thanks!
I've set up our builds so that they use a custom $(BranchToBuild) parameter which is inserted into all the build paths within the build. This eliminates the problem you have in the 'projects to build' section of the definition.
This parameter can then be passed into the build by adding a /p:BranchToBuild=2.10_2 to the build parameters in the Queue Build dialog, so you can manually select any branch to build from with every build you queue up.
You can also set the default parameters within your build definition so that it defaults to /p:BranchToBuild=2.10_2 for every build - each time you make a new branch the "current" one you can just change this default and all subsequent builds will automatically use the correct branch (but you can still go back and do a build off any previous branch easily, for example if you have to merge a bug fix back into a previous release)
The only hassle with this is (as you've spotted) that you have to also map the code for the branch onto the build server for it to be got from source control. There is a shortcut for this though - in the build definition, select all the mappings for your old branch (10.1_1) and copy them. Paste into a text editor and you'll see that each just becomes a simple line of text. Now you can globally search and replace 10.1_1 with 10.1_2, then copy and paste the entire set of mappings back to the build definition. Miles faster and less error prone than manually editing every line in the mappings.
All the above means that setting up a new branch takes me about 30 seconds.
The caveat is that the build definition points at the vcproj file that controls the build, and it gets this file before it runs the build itself. It is therefore problematic to put your build definition inside the branch. Generally this is not a problem, but occasionally when you need to update the build definition it can therefore break your branches unless you also manually point the build definition at the correct variant of the vcproj. Generally I get around this by avoiding breaking changes in the build, so it has only bitten me once in the last 7 years.
I have my automated builds working but I want to be able to go back to a specifc labeled version and build from that source. The build definition under "Process" has the item "Get Version" but this is for a specific changeset which seems fairly useless. Does anyone have any idea how I would go about doing this?
The Get Version accepts what TFS calls an versionspec which can be either a changeset or a label. To specify a label just prefix it with an L.
LMyLabel
#Dylan Smith: Is right. You can specify in the advanced Get Version parameter the label by: LmyLabel or CmyChangeset in order to queue a specific version. There are other options like date, "W" (Version last fetched to your workspace), or "T" (latest version) as well.
For more information: Building a Specific Version with Team Build 2008
During your build process, label the code (In my case I use the build number as part of the label).
Then when you want to build a specific labeled version, pass the label to the build script, get the code from the library by label, build the code, and deploy.
See http://msdn.microsoft.com/en-us/library/fx7sdeyf.aspx for how to get a labeled version.