After the BUILD conference (September 13 – 16), there was a lot of buzz about the next version of TFS. From the conference we heard that vNext was going to be a revelation. Since reading about it, and trialling it for myself (with Hosted TFS), I feel that the TFS team have fallen short of the mark, for me, on 1 of the major features they offer (there are more but I will stick with this one):
The current frustrations with TFS seem to be around painful version control problems. They include the workspace creating read-only copies of files locally that still need to be ‘checked out’ before they can be edited. If you delete a file from the file system then TFS doesn’t (currently) see that the file has been deleted. It has also been reported that ‘Get-Latest’ doesn’t realise that some files have changed when they actually had. Offline mode didn’t work well apparently when it came to a re-sync. The list could go on.
I thought that feedback would have been taken on-board that the version control side of TFS was not fantastic. A lot of people have started to look for alternative ways to use a 3rd party VCS tool with TFS. I honestly thought that Microsoft would allow 3rd party tool integration into TFS. This hasn’t happened.
Improvements to TFS version control side of things were made. These included the idea of ‘Local workspaces’. This is a copy of the files locally that are not read-only. Changes to the files outside of the TFS environment will be picked up by TFS. Another change was to offline mode. When the system came back on-line then everything automatically re-synced.
My initial thoughts when I had heard about ‘Local Workspaces’ was that Microsoft had finally hit that DVCS style system. I tweeted about this and was soon told, by a TFS development manager, that this was very much not the case. You still have to communicate with the server in order to do a ‘get’, ‘commit’ etc. This becomes interesting when you work with hosted TFS.
What happens if I am working whilst commuting and do not have network access? You can still work as you can edit files locally and TFS sees the changes, as the improvements suggest. But the idea of everything automatically syncing when back on-line worries me. Its never that easy – look at merging with VCS systems – it can be a real pain. You cannot stage local commits with TFS local workspaces. Its sounds good – a local workspace – when in reality it is only a SVN style of VCS. This can be good – but not for when working in an offline mode.
What I think Microsoft should have done it to move straight towards the local workspace being a DVCS style system. This would be the most useful approach for those who would be using hosted TFS in an offline format – a lot of developers do actually travel and work whilst doing so. I could then work locally and when I have a network connection push my local changes back to the TFS server.
Developer needs in a VCS have changed. The rise of DVCS style systems have made this happen. Therefore implementing a CVCS style of system feels as though TFS is going back to 2000, when SVN was first introduced. It doesn’t feel like it is moving in a tangible way to that of developer needs. TFS takes care of a lot of the ALM cycle – it has a CI style tool, version control, bug tracking etc. but as long as I have Git, TeamCity and YouTrack then it is not something I feel I could move towards. It feels very old fashioned in comparison to these tools.