You're exactly right, of course - my mistake. The cloaking I referred to solves a different (but related) problem - where you want a given build type (say for a particular branch) to only grab the subset of the tree you're interested in, rather than doing a recursive get on the whole team project.
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Hunter Sent: Wednesday, May 02, 2007 7:12 PM To: [email protected] Subject: RE: [OzTFS] TFS Build "UpdateAssociatedWorkItems" Hi Scott, Thanks for your reply. I've managed to find a different way of doing it - although cloaking may work - but I haven't tried it. I stumbled across this link http://blogs.msdn.com/manishagarwal/archive/2006/04/12/574715.aspx where Manish (the blogger) explains how to do it by changing the scope of the label. Basically, because the work items "integrationbuild" field is set based on the source code changes between the last build label and the new build label, if you narrow the scope of what is labelled during the build then it will narrow the work items that are included. So basically I just appended the section of xml that he included in his blog my build project, changed the GetChangesForFolder section to include the path in TFS Source Control that I wanted to related the build and also set the recursive = true property of the label (otherwise it default to false?) and it worked. Manish's code can be found below (in case his blog disappears). I'm still toying with it but initial results are good. Cheers Matthew Hunter <PropertyGroup> <GetChangesetForFolder>tfspath</GetChangesetForFolder> </PropertyGroup> <Target Name="CoreLabel" Condition=" '$(IsDesktopBuild)'!='true' " DependsOnTargets="$(CoreLabelDependsOn)" > <!-- Label all the latest non deleted files in workspace --> <Label Condition=" '$(SkipLabel)'!='true' " Workspace="$(WorkspaceName)" Name="$(BuildNumber)@$/$(TeamProject)/$(GetChangesetForFolder)" Version="W$(WorkspaceName)" Files="$/$(TeamProject)/$(GetChangesetForFolder)" Child="$(ChildLabel)" Comments="$(LabelTaskComment)" Recursive="true" /> </Target> _____ Matthew Hunter Senior Developer Stargate Group Level 4, Victoria Street Richmond Victoria 3121 Telephone: 03 8420 3000 Facsimile: <http://www.stargategroup.com.au/> www.stargatetech.com.au This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. No responsibility is assumed by the company or its employee to any other person for any loss or damage (whether caused by negligence or not) arising from the use of the information and advice contained herein. Finally, it is your responsibility to check any attachments for viruses and defects before opening or sending them on. _____ ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Colestock Sent: Tuesday, 1 May 2007 11:44 PM To: [email protected] Subject: RE: [OzTFS] TFS Build "UpdateAssociatedWorkItems" If you have builds that don't encompass everything in your team project (e.g. multiple branches, or just distinct solutions) then I believe you want to "cloak" the portions of the tree not involved with a build in the build's workspacemappings.xml. e.g. <InternalMapping ServerItem="$/Integration/BizTalk/Test" Type="Cloak" /> That is how we made sure that builds for particular branches didn't have the problem you are describing. Scott Colestock www.traceofthought.net ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Hunter Sent: Monday, April 30, 2007 1:03 AM To: [email protected] Subject: [OzTFS] TFS Build "UpdateAssociatedWorkItems" Hi Guys, I have a problem with associated work items and how they linked automatically to a build. When I do a build, it picks up all the work items that are associated to files and updates the "integration build" field in the work item to map to the build. This is great. My issue is that it updates the "integration build" field for every work item that has a new change set related to it, regardless of whether that change set is part of the build (solution) that is performed. Does anyone know how to stop this from happening? Is there anything I can do to control which work items are updated via builds? Cheers Matthew Hunter ________________________________________ Matthew Hunter Senior Developer Stargate Group Level 4, Victoria Street Richmond Victoria 3121 Telephone: 03 8420 3000 Facsimile: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. No responsibility is assumed by the company or its employee to any other person for any loss or damage (whether caused by negligence or not) arising from the use of the information and advice contained herein. Finally, it is your responsibility to check any attachments for viruses and defects before opening or sending them on. ________________________________________ OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
<<image001.gif>>
<<image002.jpg>>
