The egg and batter argument



I'm new to Team Foundation Server and I've been using it at my new company for a while. I instantly miss a lot of the features of git such as local branching, unified diffs and powerful commands for comparing branches to each other. Whether Agile or not, you've broken your work down in to a series of changes each building on the previous work. You deliver in small chunks that allows code review and testing to happen earlier. One of my pieces of work involved hooking a few screens up to a new shared function I wrote. So the first piece of work is this function and the first screen. I shelve the work and get it code reviewed and checked in. It takes two hours to go through the code review and gating process, so during this period either I have the changesets duplicated locally or I can't use the code. Team Foundation Server, after having finished gating the software will "reconcile" my workspace, separating my genuinely new code from the code that I kept around after the check-in for the sake of building on top of it. The duplicate code gets removed from my changeset (working changes). However, not before someone has had to accept it as a part of the next code review for the second part. It's quite strange and quite unattractive. The thought of having to code review something twice because the version control system isn't very smart.

It isn't fair on Microsoft however to lambaste their product for being shit if the problem is me. It took a while for me to get my head around git and to truly start using those powerful features that supposedly take it beyond any other version control. Since I had invested that time in git, it only seemed fair I invest my time in trying to understand Team Foundation Server. Certain daily productivity tools really are worth investing your time in learning and version control definitely fits the bill so I start to read up on TFS. However the more I read about the typical TFS workflow and approach the more I start to worry.

The company I work for, as well as doing code fixes, also has us spend considerable time (like a week a month) doing "Forward Integrations". This can be simply and accurately described as copying and pasting code by hand from one branch to another because they afraid to merge the old branch back into the main development branch. It isn't a 100% true copy and paste either. SQL Updates have the task number against them so you end up having to go to TFS's workflow stuff to see if the expected bug fixes are there and after this crazy practice you can't just diff the branches to spot genuine differences as the same fixes may come up under different files. It's a crazy concept that I just cannot comprehend and when I question those in authority at my company - the answer is that they don't really get version control at all. That's why they trust in Microsoft in the first place.

If there are changes you don't want preventing you from merging... cherry-picking is another great technique to avoid that. I used to use it all the time. Forward integrations in 30 seconds. A lot of the supporting documentation, which may or may not be officially sanctioned by Microsoft really discourage the use of cherry picking which I just don't understand. The argument, one of which is here goes like this:


The challenge is somewhat like following a recipe for baking a cake:

In a medium bowl, cream together 1 Cup sugar and 1/2 Cup butter. Beat in 3 eggs, one at a time, then stir in 2 teaspoons vanilla. Combine 1 1/2 Cups all purpose flour and 1 3/4 teaspoons baking powder, add to the creamed mixture and mix well. Finally stir in the milk until batter is smooth.

Oh, sorry. I meant to say: Beat in 2 eggs. Go ahead and remove one of the eggs from the cake batter. Simple, right?


This argument is a bit lame and doesn't really make sense to me. Who is "mixing" the eggs exactly? What does mixed up code look like? I once went through a huge web application and added [% csrf_token %] to about 500 <form> variables for CSRF protection. I once went through a different web application and turned every on screen text field into ##GT_xl('MENUBAR_TITLE_CODE')## so that we could add translations to our system. However, that's very much the exception. The time when it's worth creating a branch for that work.

We all strive to structure our code cleanly. To reduce coupling, to encapsulate behaviour and to modulise. Software is not, and should not be a cake mix. If the ingredients to a software project are eggs and flour the eggs and not broken and delicately placed on top of the flour and not whisked together. That's my view. A cherry pick is taking a changeset and moving it to another branch. In the same way that two people can merge their software together by checking out a change, reconciling their workspace or just pulling the latest changes, a cherry pick is no more complicated or harder than that.

I'm starting to believe the people who use Team Foundation Server either buy in to the poor excuse that "it's also lifecycle management", who I'll refer to this article. For the rest, I'm starting to believe that if they were to invest in git.. they would truly adopt a much faster, more responsible workflow that didn't involve performing redundant tasks or being scared of merges.

At the end of the day, changesets are changesets and if you trust "getting the latest changes from the server" you may as well also trust cherry-picks as they are the same thing. A diff is a diff whether it's lines added or not. Having to apply a few diffs in the same order doesn't qualify as dangerous either. Trust yourself and your version control and don't fear merge conflicts. They are just simple questions and as long as you test your code after making the merge there is no danger. Be smart and use the tools because 90% of the time they work perfectly and when you get a conflict you've still reduced your forward integration overhead from a week per month to a few hours per month.

Some but not all of the features I've talked about are addressed in an ugly command line tool called TFS Powertools. I'm still digging into it however their poor and limited execution and the fact they don't come as standard really make me feel Microsoft isn't encouraging good practice here.

I believe Team Foundation Server encourages shy and defensive programming that then damages productivity and scares developers off version control almost entirely from what I can tell looking around this lack lustre development team I've just joined. Developers who don't wish to master version control are very difficult to work with. My rule is that if it's a core tool such as your IDE, text editor or version control.. you should really invest in mastering it. There are few excuses not to.. especially in a large development team. Also, if you want to learn.. you may as well learn the best on the market git.