Hi Guys,
we have a number of different solutions inside a single TFS Project. We have create a number of team builds designed to build single solutions. Initially we had a performance problem building a solution as the entire source code repository was being retrieved before doing a build. To correct this we have cloaked unnecessary source paths using the workspace.xml (opt-out). While this works the problem going forward is that new solutions are automatically included which means that all of the team builds need to be updated to exclude the new solutions.
Is there a way to exclude all solutions and only opt-in Wildcards are definitely forbidden, is there any other way to achieve this
Another possible option I have explored is to map to a deeper level in the source tree, the problem with that is there is common code libraries which we rely on the location for their reference (no dependancy replication here).
Ideas How do other development teams handle this
Regards
Mark
Workspaces opt-in rather than opt-out
Hot Topic
- What three improvements would you suggest for DBPro setup process?
- Newbie setup problem
- How to display the function of the button when the pointer hover over the button?
- error 1402 installing virtual server 2005 R2
- Skelton Windows Application in "Win32 Console Application" will not compile
- Unit Testing
- get latest on checkout macro
- Problem attempting to customize a workflow
- Creating Icons
- ASP.Net Templates?
VS Team System
- Cannot create a new project/solution
- List of Workspaces for a given Team Project
- Work Item - Task
- Move pogam
- Can I use the XML/XSD schema as a source for data genaration?
- Rename project
- How to automatically create workitem when Team build fails?
- grrrr - registering
- syntax code
- Width Sizing of a Work Item Form
Workspaces opt-in rather than opt-out
Scott Nonnenberg MSFT
I think mapping deeper levels is more robust. That way new folders will only be added to the build when you explicitly add a mapping for them. I don't see why this would hinder referencing the common libraries. You just need to make sure the relative paths stay the same. For example:
Old (opt-out):
$/teamproject -> c:\code
[cloak] $/teamproject/nobuild
[cloak] $/teamproject/nobuild2
New (opt-in):
$/teamproject/proj1 -> c:\code\proj1
$/teamproject/proj2 -> c:\code\proj2
$/teamproject/common/commonlib1 -> c:\code\common\commonlib1
$/teamproject/common/commonlib2 -> c:\code\common\commonlib2
This will be somewhat easier in Orcas. You will be able to add positive mappings (opt-in) underneath cloaks as well as one-level mappings (non-recursive wildcards).