J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

Code Sharing in Team Foundation Server

Code Sharing in Team Foundation Server

  • Comments 4

How do you share code in Team Foundation Server?  That's what our team is working through at the moment.  We're looking at what's working, what's not working, and what should customers be doing.

Here's how we're basically thinking about it so far:

  • There's two main code sharing paths: source and binary.
  • Within source code sharing, there's two approaches:  workspace mapping on the client and branching on the server.
  • The key issues are how to deal with parallel development and how to share across projects

Here's what seems to be our emerging guidance:

  • If you're coding in parallel, and you need real-time updates, start with workspace mapping.
  • If you need periodic snapshots, or if you need isolation from the changes, then consider a branching approach.
  • If the source you need to reference is relatively stable, then consider using the binary.

The problem with workspace mappings is that they're developer specific.  Each developer will need their own mapping.  You'll also need to lock down permissions to avoid accidental changes.  Branching has the advantage that you can be explicit about taking changes, so you have stable builds but with the overhead of merging.  You can branch within the same project or cross-project.  A separate project might make sense if you have multiple projects consuming the code.

I need to still look across more customer sets, but so far I mostly see binary reuse.

I'm particularly curious in any lessons or insights those of you would like to share.  I think this is an important area for effective source control practices.

  • We are using binary sharing (using a common library for multiple projects). That combined with TFSIntegrators great "dependency replication" feature works really great for us.

    In short: When the librarys "Release" - build is successfully built the "dependency replication" feature automatically checks in the resulting .dll in our depending projects "\trunk\dependencies". And that is causing a CI-build of the depending project to be started immediatly and there by giving "instant" feedback if something has been broken by the library changes.  

    More info on TFSIntegrator here:

    http://notgartner.wordpress.com/2006/09/18/getting-started-with-tfs-integrator/

  • We use a combination of these approaches. For all Third Party components we use binary sharing since these are fairly stable.

    Within the project itself we have multiple solutions and these are shared via workspace mapping unless part of the team needs to be isolated then we make a branch.

    There is one other case where we use binary sharing and that is because the other project is still on .NET 1.1 so that team builds their assemblies and checks them into another project source control tree in an assemblies folder.

  • We assembled a solution which resembles a lot the solution you are offering and supports paraller development:

    http://blogs.microsoft.co.il/blogs/srlteam/archive/2007/03/14/VSTS-Source-Control-tree-structure-which-support-Concurrent-development-_2600_-Versions-management.aspx

    I agree that the combination of multiple braches and a workspace mapping manipulation is sometimes complicated to handle, but it gets the work done :)

    Sarit Tamir

  • The Sandcastle Blog on Announcing March 2007 Sandcastle CTP Technical Refresh. J.D. Meier on Code...

Page 1 of 1 (4 items)