locked
What should be stored in TFS? RRS feed

  • Question

  • I was looking at a developer's TFS workspace the other day and noted it contained 3rd party tools, including dll, exes, and libraries (about 18GB worth!) . I was surprised to see that, expecting only to find source code files (text files and the like). I asked where all these dll's etc came from and he said they are stored in TFS as part of a "Common" project. Apparently when a new project is created the Common project  is pulled down to the local workspace. He guessed that 75% of those libraries are not needed in any given project.

    I think that only source code should go in the TFS workspace and 3rd party libraries, etc should not.  Then he can easily shelve just the source code, not the entire 18GB, at the end of the day. (Also think of the amount of redundant data being backed up to tape if we backup the dev workspaces on each dev's box.) 

    How do you deal with this issue of intermingling source and exe, libraries...?

     

    TIA,

    Barkingdog

     

    Friday, August 19, 2011 8:12 PM

Answers

  • Hi,

    I worked on for a client where the development model was split onshore offshore, to make sharing of tools and in order to ensure that the team all across was using the same version of common tools, the teams across the globe checked in common tools to a team project and referenced that team project. Now as we started growing, we realised that the common project became unmanagble since every developer as part of the workspace refresh downloaded the common team project as well to pull down tools or third party libraries that they did not need. So, we decided to do a bit of cleaning up and set up some guidelines and process around this.

    1. The common project was split in to 3 folders, a. External softwares. b. External dlls and c. External Project Refs. You can break this down further, but logically speaking, the developers only needed "c. External Project References" to build their solutions and a and b were really a sharing mechanism to ensure that the team uses the same version of tools and external dlls.

    2. Once the above logical split was set up, all developers were asked to reset the workspace mapping on common project to only map common project/external project refs. An exception report was set up using the tfs api to read all workspaces and validate that the workspace mapping on common project was not accidently set up to the whole bunch.

    3. The developer distribution list was set up and registered for notification on the common project, so every time the version of a tool or external shared dll was refreshed on the shared project the team would get alerted and those who needed the tool could download the latest version from the server after they would download and install the tool they would clock the workspace mapping.

    4. Now since common project was not part of the workspace mapping, it would not be checked out or modified by a developer, which means during the shelve operation in would not be included. And to be honest shelve is really a snap shot of the current state of the workspace i.e. a reference mapping and not really a physical store of the files, so it would not have a major impact on the backup operation. But in the hindsight it is import to keep a clean server regardless.

    We also set up an exclusion report to monitor workspace size, later to discover that some of our developers checked in MP3's in the source control to share their favourit albums with their fellow developers across the continet :) this forced us to set up file exception check in policy to deny check in of various file types and when the policy was overridden an alert was sent out to the tfs team and easily track why the policy was overridden.

    You should even promote shared refs in a seperate folder in the same project as well, see a sample in the screen shot below.

     

    Hope this points you in the right direction, in case you have any follow up questions feel free to add to the thread.

    Cheers,

    Tarun


    Please remember to mark the replies as answers if they help.

    Tarun Arora

    Blog: http://geekswithblogs.net/TarunArora  Subscribe in a reader

    Friday, August 19, 2011 11:27 PM

All replies

  • Hi,

    I worked on for a client where the development model was split onshore offshore, to make sharing of tools and in order to ensure that the team all across was using the same version of common tools, the teams across the globe checked in common tools to a team project and referenced that team project. Now as we started growing, we realised that the common project became unmanagble since every developer as part of the workspace refresh downloaded the common team project as well to pull down tools or third party libraries that they did not need. So, we decided to do a bit of cleaning up and set up some guidelines and process around this.

    1. The common project was split in to 3 folders, a. External softwares. b. External dlls and c. External Project Refs. You can break this down further, but logically speaking, the developers only needed "c. External Project References" to build their solutions and a and b were really a sharing mechanism to ensure that the team uses the same version of tools and external dlls.

    2. Once the above logical split was set up, all developers were asked to reset the workspace mapping on common project to only map common project/external project refs. An exception report was set up using the tfs api to read all workspaces and validate that the workspace mapping on common project was not accidently set up to the whole bunch.

    3. The developer distribution list was set up and registered for notification on the common project, so every time the version of a tool or external shared dll was refreshed on the shared project the team would get alerted and those who needed the tool could download the latest version from the server after they would download and install the tool they would clock the workspace mapping.

    4. Now since common project was not part of the workspace mapping, it would not be checked out or modified by a developer, which means during the shelve operation in would not be included. And to be honest shelve is really a snap shot of the current state of the workspace i.e. a reference mapping and not really a physical store of the files, so it would not have a major impact on the backup operation. But in the hindsight it is import to keep a clean server regardless.

    We also set up an exclusion report to monitor workspace size, later to discover that some of our developers checked in MP3's in the source control to share their favourit albums with their fellow developers across the continet :) this forced us to set up file exception check in policy to deny check in of various file types and when the policy was overridden an alert was sent out to the tfs team and easily track why the policy was overridden.

    You should even promote shared refs in a seperate folder in the same project as well, see a sample in the screen shot below.

     

    Hope this points you in the right direction, in case you have any follow up questions feel free to add to the thread.

    Cheers,

    Tarun


    Please remember to mark the replies as answers if they help.

    Tarun Arora

    Blog: http://geekswithblogs.net/TarunArora  Subscribe in a reader

    Friday, August 19, 2011 11:27 PM
  • Thanks Tarun for your great post.

    Hello Barkingdog,

    Does Tarun's reply help you? If you still have anything unclear, welcome back.

    Thanks.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, August 24, 2011 5:07 AM
    Moderator