Suggestion for Team Development please...

neal007 · Post by **neal007** » Mon Dec 25, 2006 12:59 pm

Hello SG,

I'm a Micro ISV but have several subs that will be working with me on a new project. I have a solution in VS 2005 with about 5 projects with more to come. Each dev will work on various features but will need access to the "core" project (MDI app) to build in the integrations to launch and use their assigned areas.

There are options that I can think of such as creating separate branches and merging them (Joel Spolsky's article recently), or just have them each do their stuff in their own assembly (VS project) as part of the solution.

How do YOU guys team dev in the creation of Vault? What are suggested practices for multiple developers to use Vault without locking each other out, or forgetting to check files in, etc. What is the typical team development practice using Vault that you see?

Thank you for any suggestions on how best to use Vault to help with disconnected team development.

lbauer · Post by **lbauer** » Thu Dec 28, 2006 9:05 am

Our team isn't *quite* as large as Microsoft's, so we don't the same concerns about developers tripping over each other.

We have a repository for each product (Dragnet, Vault, Diff/Merge).

Our development trunk has folders for discrete portions of the application -- the web service, IDE client, Admin Tool, etc. Specific developers generally work on a particular feature.

When a release is done, we branch, with work for the new release continuing in the trunk. If we put out a maintenance release for the current version (3.5.1, for example), those changes are merged into the trunk (currently 4.0).

What are suggested practices for multiple developers to use Vault without locking each other out, or forgetting to check files in, etc.

Although a user can check out a file exclusively, the default for a repository is to allow multiple checkouts, with the capability to merge changes. Also, the Vault Admin can undo a checkout in the Admin tool if your developer has decided to take an extended holiday.

Enforcing your development policies may need to go beyond source control. For instance, we used to have a rule at SourceGear that any developer who broke the build had to buy doughnuts.