To Skip this Intro, read the full article here:
A Simple Version Control Strategy Using Team System
I was recently asked by a client who I'm helping to integrate Team System, to create a strategy for the organization and future projects for managing multiple versions of applications and code - A version Control Strategy.
Since there are some major difference between the way Team System Works and its current abilities compared to past versions of Microsoft Source Control Products like VSS (or other 3rd party products such as CVS), I turned to look for a good source of information on this. The more I searched I less I found that made sense. There are tons of scattered material out there on the technical aspects of version control (very little on Team System but there is some) but almost none about the strategy you might want to use when dealing with multiple versions.
I asked several of my colleagues, all working with Team System, to tell me what strategy they use for versioning control of applications. They all said that they are also “re-inventing the wheel” – They couldn’t find any clear guidance either on this.
So I decided to put my (oh so simple) thoughts on paper and publish it, so that :
- I can get feedback
- You won’t have to reinvent the wheel yourself.
It’s important to understand that besides the simple “What do I do when I have a new version”, the technicalities of what you do in team system were compiled from other sources, mainly the one listed at the top of this page.
This short guide is nothing more than that –a short guide, that tells you the basic strategy you need to follow. That mindset is what’s important. It’s not a 90 page document. It’s a strategy document, and as that is should be simple.
Over time I will sprinkle various “HOWTO” links around the article to point to various “gotchas” when trying to accomplish some of the stuff mentioned here. A good example might be coming up with the appropriate versioning scheme that automatically changes the last build number based on your input. It’s a relatively simple task, but with the current crop of Team System Tooling (namely- none), it’s pretty hard to achive without lots of manual labour. I will add that link later on when I’ve written a short essay on those little pitfalls we like to call “Extending Team Build”.
The article is in the form of Questions (FAQ) that you ask yourself during development. The first two are just background and opening though. Hope the format is useful.
Read it: A Simple Version Control Strategy Using Team System