views:

518

answers:

2

I am wondering what is the best way to use workspaces in visual studio. We have 150+ webservices that are all part of the same team project $/MyTeamProject without being related at all. The reason for them all being part of the same team project as they are all maintained by the same group of people within our organization.

Each webservice has the following structure

$/MyTeamProject/WebService1
$/MyTeamProject/WebService1/Main
$/MyTeamProject/WebService1/Release/1.0
$/MyTeamProject/WebService1/Release/1.1

$/MyTeamProject/WebService2
$/MyTeamProject/WebService2/Main
... etc.

I am wondering what is the proper way to use workspaces with this setup as currently there is only mapping for the teamproject so all my webservices are part of the same workspace. Should I create mapping for the main branch and for each release branch as a separate workspace or should I map each webservice to its own workspace such as $/MyTeamProject/WebService1?

Any help would be appreciated.

I can't put each of the webservices as its own teamproject as the tfs is being shared between several groups with the same magnitude of projects and therefore we are limited by our own teamproject for all of the webservices.

A: 

If you have one workspace per webservice then you will get 150*#releases workspaces. This will get really hard to manage for build versions, labelling etc. Fewer workspaces will mean less builds to manage.

I would recommend having a workspace per release. Generally you would probably only be working on one release at a time and this will allow you to manage all code for a single release effectively. Also you can then map your workspaces on the client into a more logical structure as you allude to in the question.

For example

\Projects\MyTeamProject\Main\WebService1
\Projects\MyTeamProject\Main\WebService2 ...

\Projects\MyTeamProject\Release1.0\WebService1
\Projects\MyTeamProject\Release1.0\WebService2 ...

\Projects\MyTeamProject\Release1.1\WebService1
\Projects\MyTeamProject\Release1.1\WebService2 ...

etc

Liam
Well what if Webservice1 and Webservice2 are completely unrelated and are not considered to be part of the same project - only that the same team is working on both of them. How would you go about that? Release 1.0 of WS1 does not imply Release 1.0 of WS2?
Fadeproof
You could still use the same structure. Map the 'current' working release of each WebService into the workspace for each team. Each web service can still be released separately because it would generally be your build system that produces releases, not the developer workspaces.
Liam
+1  A: 

You said that the webservices was not related at all. I then assume that they are released separately.

I can't see any reason to use multiple workspaces in your scenario. I suggest that you remove the mapping from the top level project "MyTeamProject". Then you have flexibility to map the subfolders to whatever local folder you want.

Petter Wigle
Problem is that VS pending changes lists pending changes in any of the webservices as they are all part of the same workspace which makes checking in changes a bit fragile - is there any solution for that?
Fadeproof
One solution is to shelve the pending changes that you are not currently working on. When you shelve you can deselect the option to "Preserve pending changes".But why do you have som many pending changes? It is a good practice to make small changes and check in often (at least once every day).
Petter Wigle
In the pending changes window, click the "Filter by solution" button.
Richard Berg