Ok. In my month and half long absense it was decided to go with Team Foundation Server (TFS) by one of our team leads working under my architecture. And I saw everything was going smooth after I came back. In my absense this lead got permission to use his personal laptop to work on the system because he was leading two remoted locations. Everything went fine until he was moved to a different project at a different place with a different client. So before he was asked to go to a different client, he checked out web.config and remember that the workspace he was using was on his personal laptop. He never checked it in and moved on. That is the history.
Now the story begins. I have taken over the responsibility of TFS. Now the team realized that the web.config is not accessible and is giving compile time errors. Team decided to work offline for web.config and make their version as writable. This is a temporary solution and will not workout in release management which I am responsible of. I looked on the net, and of course on msdn for help. I don't blame Microsoft for not having documentation for beta product, but atleast they should not have created key based on developer workstation id to bind the file information (checkout, checkin, lock etc. issues). My admin privileges are not helping either. Logging in into the system using that user id is also not helping and throwing web.config has been checked out and locked on a different workspace. Remember TFS is still beta and uses SQL Server 2005 for all of its activities, which is cool. It looked like there are only two choices left for me.
1. Delete all the rows by selecting the rows based on that lead's personal laptop name (workspace name in other words).
2. Or build new TFS system.
I do not want to do 1st thing because I am neither sure nor familiar with the architecture of TFS. I am still learning the system and making myself familiar with.
I do not want to do 2nd thing because I might end up losing some of the development stuff that is going on. But looks like I do not have any other choice, so I decided to build a different TFS system in parallel to the current one and migrate data and bring down the old one and bring up the new one. But there might be some issues associated, which could come into picture in the last moment, and there is no gaurantee that I could drop that web.config file so easily. There is no gaurantee that I get all the code checked in before I migrate to a new system, because teams are dislocated and working in different cities and places.
So I gave a deep thought. Suddenly it occurred to me why can't I change my workstation name to the name of that workspace that checked out the web.config and use that user id, which was used to check out the file. I changed my workstation id, rebooted the box, used that user id to log in into TFS and checked in the file. But here is the catch associated. Since the laptop that was used to check out the file is missing, it threw some warning saying all the changes would be lost since the web.config in this case is missing from the workspace location (since the workspace that actually checked out the file was hosted on a different system). I did not care for that, because the changes were not that important, we could recreate it. But remember if there are more files checked out, then you end up losing a lot of stuff. Sometimes it might be total development.
May be there is a simple solution to that. I checked on MSDN2, there is a command line utility called TF that could be used to unlock the files and release them for editing, but I could not find it in our installation. Probably that is still in beta and once they release it, that would be there and eases these kind of issues.
Lesson learned: never let any developer or team member to use personal laptops, external hard disks, ipods etc. to create their workspaces. Hey, that was not my permission to let him use his personal stuff in the first place. Next time I would definately resist.
Originally published at blogs.wwwcoder.com.