Does anyone have experience using Team System to version and manage objects like Word documents (e.g., design specs, test plans, etc.) in addition to source code? Pluses/minuses? Would you recommend doing this based on your experience?
Thanks.
Hi CarlaOR,
In my environment we use version control for all documents. We have one tree for the entire team of approximately 30 people. With check-in policies turned on for source control, the process isn't as friendly for the non-developers, so we have decided to move all non-source code files to a second team project.
With the next release of SharePoint Services, we will most likely store all non-source code files at the SharePoint level.
Hope this info helps...
Ben
Thanks Ben, that helps.
Can you clarify what you mean by storing the non-source code files "at the SharePoint level." By that do you mean going directly to the SharePoint library that is supporting Team System? If so, how is that done and is it easy for non-developers?
Thanks.
Hi Carla,
The team is familiar with using SharePoint and they are able to access office documents via the browser (http://server/sites/Team Project Name), or they are able to access them within the TFS Explorer under the 'Documents' folder. In either case you are referencing documents at the SharePoint level. From my experience, I would say it is a simpler process to access documents within the TFS Explorer because of the differences between using a Win app versus a Web app. If I want to edit a document at the SharePoint level within TFS Explorer, I right-click on the document and choose edit. When I am done with my changes, I just save and exit. Of course there is more flexibility when accessing these same documents from a website because you can access them from a browser instead of from the TFS Explorer client. The browser is probably more readily available on a desktop than the TFS Explorer.
Also, as we move further into the world of TFS I doubt we will want to buy TFS licenses at $499 per to access office documents at the source control level versus accessing office documents at the SharePoint level, which doesn't require any additional licenses.
Ben,
May I ask how you went about creating the "second team project" such that it was specific to non-source "projects". I've tried doing the same thing, but when I try to create a non-source project all of the default infrastructure is still created (e.g., work items, documents, reports, team builds, etc.). I don't want any of that stuff. I really just want an empty, top-level folder created in the source control tree. I can't imagine that this should be hard, but I can't seem to make it work.
BTW, I'm using the released version of the Team Foundation Server and client tools.
Thanks,
Chris
Hi Chris,
The second team project I created includes all of the project infrastructure items you mentioned above. For us, it's a temporary solution since we will move non-source files to the SharePoint level at a later date.
Regards,
Ben
Ben,
We considered moving these types of documents to SharePoint as well. However, it appears that SharePoint does not have sufficient granularity of access control to do so. You can customize the access control for an entire document library. However, I have seen no mechanism to customize access control for particular folders or files within a document library. Have you found a way to solve that problem, or is such a level of access control not a concern for you?
Thanks,
Chris
