views:

30

answers:

3

We are a software product company and our product codebase naturally gets branched for different projects. We currently use TFS2008 configured to store documents in SharePoint 2007. Both of these will be updated to 2010 versions, starting with TFS.

We'd like to branch - and not just version - our specifications so that any release from any code branch can be tested against a matching version of the spec.

It seems to me that we can either:

  1. Keep our specs in SharePoint, using SharePoint search and versioning, and fake the branching issue by use of naming conventions or subdirectories
  2. Move our documents from SharePoint into TFS proper. Enjoy the free versioning and branching, and quietly mourn our lost SharePoint document management goodness
  3. Find some magic plug-in that gives us the best of both worlds?

Does anyone have any experience of any of these options?

A: 

I think I would go for alternative 1 by considering this: If your documentation is e.g. in MS Word, branching will give you nothing in terms of merging. That will never work with binary files.

If your documentation actually are text-based documents, I think I'd still go for 1, considering search capabilities, views etc. that you get in Sharepoint.

flq
I should have mentioned that our specs are, as you suggested, in MS Word. As you say, I don't care about merge for these documents, I think the main problem for option [1] is having to branch the various specs manually.
Francis Norton
A: 
  • Using SharePoint is a big advantage because it is easy to access\
  • Having the documents in TFS is a big advantage because the code and documentation are synced per version

It really depends on what your real needs are. If you have a shop where you have many people who have to access the documents only once in a while, probably the SharePoint advantage wins over the sync feature in TFS. If you only have a few business analists, then probably the sync feature wins over SharePoint.

Be aware that when you store the documents in TFS, you need a CAL for every user that accesses the documentation.

Ewald Hofman
I think that this is a good way of approaching the problem, and in the absence of a silver bullet recommendation I'm going to accept it - Thanks!
Francis Norton
A: 

Here's what I've proposed as a solution, based on the answers here and on further experimentation.

First, some more background:

You can do very usable comparisons [1] between versions of a Word 2007 document held in SharePoint from inside Word (menu:Review > Compare > Compare > Specific Version...) and [2] between different versions of a Word document as separate files (menu:Review > Compare > Compare > Compare...) but you can't do version comparisons directly in TFS because it barfs on binaries.

This leaves you with an easy work-round for comparing the same document between TFS branches because both versions of the document are there on your file system (since TFS 2008 implements branching via directories) so you just use option [2] above. It also gives you a less easy work-round for comparing different versions in the same branch (or non-current versions generally) - you download the non-current versions as re-named files, then do the file comparison as before.

Now the proposal:

So I'm simply proposing we do all our specification creation in SharePoint, and create a branch folder-tree there to mirror the branch folders in TFS.

If the requirement arises, we can copy a snapshot of the related specs into TFS when the branch is released, but I'm hoping that either the branched specs won't change post-release date, or that if they do, SharePoint versioning will handle it well enough for us.

Francis Norton