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
Related
We currently have up to 3 developers working in the same branch.
In Jan, I submitted changesets (say 100-110) that have since had some code overwritten by changsets (111-300) during merges from other team members. I'm now just getting back to my project and I dread having to manually re-type all that code.
I can identify the exact changesets I need.
Is it possible to "merge" these specific changesets into the latest version of the same branch?
You can merge the changes in the same branch.
GO TO Branching and Merging option and click on the merging option you can merge the changes by choosing change set, date or label.
Hope you get my words
Scenario: Dev team has lets say 10 Work items. They resolve 8 work items and that needed changes to 50 files (checked out and checked in and during check in are associated to Work Items). They also worked on remaining 2 work items and fixed and checked in 5 files, but the work items are not completely done, so not resolved yet. Now I want to create a build with the 50 files only which are associated to the 8 Resolved Work items (and exclude from build the 5 files for the 2 unresolved bugs) . Is there a way to do that in TFS 2010?
TFS builds from changesets, so you need to find out the changesets associated with the work items you need to include/exclude. Simply browsing the history may suffice, but you may have to inspect what changesets are associated with the work items.
if you're lucky those changesets that you don't want to have included in the build are later in History, it's simply a matter of setting up a workspace containing only the history up until the changeset you need. If you're using Team Build, the default build process has parameter GetVersion that you can set to the changeset you want to build when queuing. If it's manual, you'll have to do a
tf get /version:C<changeset number>
(UPDATED) If on the other hand the order of checkins have been mixed (some of the changes that you need to exclude have been done prior to some that you need to include), the best way would be to create a branch, and then only merge the changesets you need to include to that branch. Then you can simply build from the latest version on that branch.
1)Using History, find the latest changeset with code you need (the closest prior to one you need to exclude)
2) Create a branch based on that version.
3) Do a selective merge of the other changesets you will need included in your build, skipping those you don't want.
4) Build from the Latest version on that branch.
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.
We are planning to move from StarTeam to TFS for source control and are in the midst of refining our ALM procedures. Maybe I am misunderstanding something about how labels work in TFS, but it appears that you can apply a label to files by Changeset. I am trying to create a label on only the files/versions in the specific changeset.
I have attempted to do this like so:
1) Main Menu -> Source Control -> Apply Label
2) 'New Label' dialog appears
3) Leave path as is (Dev Branch)
4) Select 'Changeset' from 'Version' dropdown, enter my changeset #
5) Click Create.
... which results in the entire branch getting labeled. The changeset may be 1 - 100s of files, so individually labeling files is not practical.
We do this all the time in starteam: label changesets related to features, then move a build label up onto the labeled changeset. Am I missing something fundamental? (Thanks for any guidance)
Note the name... you are labeling by changeset not labeling a changeset.
Labeling in TFS is like marking a point in time. So when you label by changeset you are basically saying this is what my source control looked like at this point in time.
It sounds more like you area saying you want to be able to find a set of changes (changeset) not everything at the point in time that changeset was made.
You could pick a branching strategy that would allow you to branch by feature. The downside of this is that it will involve a lot of merging.
Another options would be to link the changesets for any specific feature to a work item and then you will have a list of changesets that you will want to merge up once you have completed that feature. In 2008 this can be a little troublesome because merging changesets that are not sequential can be more time consuming than necessary. (meaning there are changesets in between on that branch not that the changeset numbers are sequential)
Fortunately, you can try out different branching strategies and as long as you think it through it isn't to tough to switch if you don't like how you were doing it.
In TFS2010 I tested adding lables to a changeset and I am seeing the same behavior you reported.
When reviewing a changeset it will only contain the files that were checked in.
When reviewing a label that was created on the same changeset it will contain all of the files in the branch, with each file showing the changeset version of the last check-in.
I don't know why it works this way.
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).