- Posted by liammclennan on October 21, 2009
Between 2nd October and 18th October my current team was using Team Foundation Server for source control and integration. On Sunday I merged the changes from TFS back into our old subversion repository, effectively throwing away the two weeks of work that one of the guys spent setting up TFS. Why did we make this decision and what did we learn?
TFS Locks Files
Like Visual Source Safe, TFS locks files to indicate that the file is not ready for editing. We do some build automation which is made more difficult by file locking.
tfs changes our source files
TFS makes two changes to the source files: inserting source control bindings into project files and adding .vssscc and .vspscc files. We prefer if our source control doesn’t modify our solution.
tfs does not let me work offline
Ok, you can work offline, but it is a pain. I had lost changes and trouble reconnecting when I came back online. We have a distributed and mobile team so working offline is important.
tfs asks me to login every time I open Visual Studio
No doubt there is a way to configure Team Explorer to remember my domain login, but I didn’t find it.
tfs requires a domain login
I am not an employee of my client, so I did not have a domain login. One had to be created for me so that I could access TFS.
tfs only remembers changes that are made through Visual Studio
I use Visual Studio to edit and compile code. I don’t use it for editing other text files, images etc. Any changes that I made to files within my project were not persisted to TFS unless I made the change through VS.
To be fair, TFS works and we could have stayed with it, but we decided the pain of migrating back to subversion was less than the pain of staying with TFS. I also found that TFS performed much better than subversion. It was a big surprise for me to find that TFS retains so many of the problems that Visual Source Safe had.