My final talk at VSLive! San Francisco this week was on one of my favorite topics – parallel development. In other words, dealing with the real-world situations where multiple developers are coding away on the same project, and even the same file.
The first order of business was to have a few of the ex-Visual SourceSafers lay down on my couch so we could discuss their phobias and irrational urge to run to their “safe place” – a.k.a. locking.
In all seriousness, we discussed the two locking models of TFS and then explored the many wonderful benefits of not using locks by default, known as shared check out. Most in the audience agreed that the benefits of not blocking each other with their routine development (for example, not locking .csproj files when somebody adds a new file) greatly outweighs the detriment of having to deal with a conflict that requires manual intervention. Of course, arguments can be made either way.
I pointed out that there are four situations where conflicts can occur that may require auto/manual merging:
- CHECK-IN – the most obvious; somebody else may have just checked in competing changes just before you
- GET – you may already have pending changes on one or more of the files you are trying to download
- MERGE – by definition; when you merge changes from one branch to another, the chances are good that you will have to resolve conflicts
- UNSHELVE – not so obvious, but this is basically like a GET, just coming from another location in TFS; unfortunately, Team Explorer doesn’t know how to handle the detection/resolving of these types of conflicts, so look to the TFPT UNSHELVE power tool for help
Finally, we looked at setting up a source control folder structure that will support your teams promotion model (a.k.a. staging environment). I proposed a simple structure, that looks somewhat like this:
Some explanations
- Code holds code artifacts – C#, VB, SQL, WiX, etc.
- Documents holds snapshots of the SharePoint site archived at the end of each iteration, release/version, build, etc. (whatever your term is)
- Active development occurs in “Current”, which you could name “Dev” or “Main” (although I prefer “Main” for integration)
- Under the “Current” folder you’ll have folders for each high-level application/component in the system, including common, database scripts, build definitions, and even setup projects
- “Branches” are just that – QA, UA, RC, Release, and private branches (Bridges), etc.
If you’d like to have a look at my slide deck, you can find it here.
