Diff debugging revamped
The first version control system I ever used was Source Safe. The few things I remember about my Source Safe experience are:- Hey, this is better than zipping code back and forth.
- Somebody has my file locked... I can't continue working.
- Check in everything when you're done.
No, at that time I was not really getting the most ouf of the version control system but now I understand old good Source Safe was not the way to go.
Most of the developers out there think about the underlying version control system (when they have one) just as a way to actually release their changes. That's it. And it is often something painful to use. Programmers don't usually enjoy using the SCM but exactly the opposite.
The thing I like the best about Plastic is that it is not a tool designed to help managers control people, but to help programmers to be more productive. Ok, you can find features to help project management, and even project control, but they are derived from programmer's productivity facilities. This is an important point to remember.
Ok, why I say that? Let me introduce the topic I'll be writing about today. I was thinking on posting about the way I use Plastic to find bugs in the code. Then I found Martin's Fowler post on DiffDebugging. Yes, whatever you think about there is always someone else who thought about it before. Ok, let's go.
Most of the people I find using SCM systems use one of the two following patterns:
- Use the SCM just to check out and check in code.
- Use a continuous integration approach.
Of course there is a huge benefit on the second approach compared to the first, because it requires a well stablished build mechanism to be present.
But both of them fail on really "helping" the programmer in his daily work. Fowler's post introduces the issue of "debugging" using diff tools. What does it mean?. Ok, as programmers we are all used to the following situation:
Hey, this was working only half an hour ago, what happened? (you can replace "half an hour" by "half a day", "week" or whatever your prefered time unit is). So if you're using a version control system you can check your file's revision history, and go back "diffing" between previous versions. It is a very handy tool to find and fix problems. With Plastic we have introduced not only a "log" or revision history, but a 3D version tree which can show both history and revision's relationships in a very handy way.
Well, it is clear that version control can even help during debugging sessions but, if you are using Source Safe, CVS or Subversion your team is probably using just one development branch: so people (as it happened on my first source control experience) just check in code when they're done. Then "DiffDebugging" is not as useful as it should be. Let me explain: using the mentioned model you just check in when everything is done, so you won't prevent the following scenario: you're working on something (still intermediate) and you have to make some major change. The usual way to prevent the it was working but now it doesn't situation is saving your code with a different name before making changes (foo.c.old, foo.c.back, foo.c.back-the-good, sounds familiar?), or even better (I wanted to say worse), commenting code in and out. This can end up with:
a) Commented code kept into the mainline for what if I need it later cases. (You won't never need it later, granted!,but the ugly commented pieces will remain there forever)
b) Programmers not getting the benefits of "DiffDebugging": problems not only arise between good revisions but also between intermediate ones, the ones the programmers are working on and will never be commited to the source code control system because they are not yet finished.
Is there a solution? Yes, there is one: branching patterns. Plastic SCM handles branching with enough agility to allow developers create as many as they want: this way they can use branch per developer or even branch per task approaches. In any of them they can check in as many times as they feel they need to (once they are used to... quite often), so DiffDebugging enters the scene again, allowing them to search for mistakes in their own ongoing work.
With extensive branching usage developers gain a big undo button allowing them to exactly check everything being modified.
Fowler states most of the time I see diff debugging is during an programming session when you have local version control. Here local version control is an added service of the regular version control system.
In fact every new age version control system will talk about private branches or sandboxes or whatever that will provide developers isolation and full advantage of DiffDebugging at the same time.
This comment has been removed by a blog administrator.
ReplyDelete