The perils of tfs source control

Tfs has its advantages – it’s nicely integrated into visual studio, it has a build system in ‘the package’ but the source control part is a bit uncomfortable for my personal workflow. The mentioned part comes from visual source safe which was discontinued (rebranded ?) in favour of tfs. Is used locking mechanisms and caused a lot of problems, but that’s one of the ‘you had to be there’ things. Tfs improved but didn’t get rid of all the problems – perhaps because it’s a tool that was initially created with and old approach to software development (my personal opinion). So what exactly is it that bothers me. There are 3 things.

The readonly flag

Tfs has a nasty habbit of setting the readonly flag on each file it controls. That starts to become a problem when you do changes outside of visual studio – which I do. As an example. I have scripts that bundle and minify static files on websites. They use tools that report an error if the output file is readonly (no suprise here). So in order to get the job done, I have to open visual studio, find all the files of interest and ‘Check out for edit’. That becomes an even bigger problem when you have these files spread across multiple proejcts. I did find a way to ease this pain – there’s a vs extension called Tfs Power Tools which can integrate with explorer and provide tfs context menu options on right click – that’s helps but that’s not what I’m aiming for.

The (lack of) speed

The speed at which tfs handles files is among other things dependent on your internet connection – and in my case – that’s not the best. When you ‘Check out for edit’ it needs to contact the server. If you have an connection interruption – you have a problem. Yes there are ways to work around that – ‘work offline’ (for which you either need to restart vs or get a plugin) – but again, that’s hardly solving the problem.

The recent things – ‘baseless merge’

I recently rearranged the repository structure a bit – long story short, the following hierarchy was the result: a –> b –> c (this is exactly the hierarchy that was displayed when I did a ‘View Hierarchy’ of branch c). Now, reintegrating from b to a is not an issue, that’s done often. This time I wanted to reintegrate c into a (because b was removed). Tfs gave me a warning about a ‘baseless merge’ that will be performed as it could not find a common root branch. Now.. this set off an internal alarm. I proceeded with the ‘baseless merge’ and as a result saw a whole screen of merge conflicts. Now this should not have happened. I mean, the diagram showed a correct structure, the fact was that it is a correct structure, but tfs wasn’t able to ‘skip over’ one branch. Lesson learned here –> if possible, rename a branch, don’t branch it… not the kind of advice if anyone would ask. I ended up with removing branch c and creating another one in it’s place (with the same name) by branching from a. That creates a direct descendant which tfs can handle.

Conclusion

I’m giving git-tf a try as soon as I find a few spare minutes.

Cheers.