This is really one of those topics where 9 out of 10 developers have been already. Your using Team System for your .Net source code repository and a copy of TFS client on each developer workstation. You assemble the team for the next project and decide on the branching / merging strategy; Branch per product, branch per release, etc.
So each developer on their workstation kicks up the TFS client software and creates themselves a workspace based on a key of “name” (usually the computers unique network name) and “owner” which supports a user having many workspace mappings on the same machine as well as different users hot-desking on the same machine. This needs to be done only once and effectively creates a cache of properties and data of interest from the TFS server onto the client machine.
The idea then is to do a “get latest” of the software artefacts of interest and let the TFS software keep a record of the mappings, what has been asked for and give the developer the chance to work locally on those changes without having to be “online” to TFS until the next changeset is due to be checked-in. Also, if you consider that not all developers sit in the same building or even at the same site (i.e. they could be connected via a WAN in 2 or more disparate locations) then it becomes clear why Microsoft has chosen this method of operation.
So heres the rub. In order to change a file already in TFS you have to check it out. This does not sound too difficult, however by default TFS does not get the latest version of the file on the server into your local workspace even if it knows you have an out of date file in your workspace when compared to the servers version of that file. Why does it do this? Well you have to know that the process of “getting latest” and “checking out” have been divorced in TFS. It is a matter of keeping things simple and reducing network bandwidth requirements! Another developer may have added a more recent version of the file to the TFS server but it could break the build / may not compile / may not be tested yet. You would not necessarily want this change brought into your workspace unless you knew what it related too. So the onus is put onto the developer to coordinate his acivities and be aware of what is in his workspace!
This can lead to some confusing moments particularly if you have changed say Version 4 of FileA (the version you asked for) but in the meantime another developer has checked-in version 5 to the TFS server! There are things that can be done such as “locking” the file when it is “checked out” or checking the server prior to “check out” to see who is currently working on what.
However, all is not lost as the “check-in” stage from local client workspace to TFS server will point out and allow resolution of all conflicts between the local workspace file version and the latest version on the TFS server.
Another way to combat this is to have at least a lightweight build process nightly to ensure that the teams software is playing nicely together. I have given a post about precompiling .Net 2.0 web sites and services and this forms part of the current lightweight build process. My current client has made a heavy investment in COM and VB6 over the years and in the current economic climate it will not be possible to convert it all to .Net 2.0 and beyond so we went for a lightweight nightly build process utilising DOS batch files. In my next post I will describe the check out and build covering both .Net, legacy VB6 code and a smattering of C++.
Happy coding!
