Dear reader of Juri's TechBlog,
I moved my blog to a new domain and a new hosting solution as well. I'm now blogging on juristr.com.

Check-in Small Pieces to your VCS!

A while ago our TFS master at work :) sent around a statistic about the "ExcutionCount" of each developer w.r.t. the TFS. The result was me on top of the "ranking" with quite a huge distance to others, although at that time I worked part-time, half the time each day as all other devs. Now, obviously this doesn't mean anything but does just express the number of interactions between a developer and the TFS system, nor does it mean that I was more productive than others :).

But still the statistic has a significance, namely it tells how the TFS (or more generally, the VCS system) has been used during the development process.While I prefer committing very small changes to the VCS, the other devs generally tend to work for a long time on different features and then from now and then they commit everything to the VCS. This (latter) approach has several drawbacks...

  1. Difficulty in assigning a proper comment to the checkin
    When you work on different features, maybe at the same time fix some bug you receive and then before lunch you checkin everything...what kind of comment would you add?? "Worked on", "Coding", ...? Yes, these are the kind of commit-comments I often encounter...In such case, better do not put any comment at all. The problem is obvious, isn't it? You did just too much at once, rather than committing your changes incrementally and more often.
  2. Difficulty in tracing / reverting changes
    Assume the extreme case where you generally commit your changes 2x a day (before lunch and before leaving work) then those commits tend to be huge, containing a lot of different (often even unrelated) changes. First of all, this makes it extremely difficult - later during maintenance - to understand how certain code pieces emerged / evolved over time and second, you somehow kill the VCS's most useful feature: reverting changes when you have broken something which cannot be repaired easily.
Therefore it is a good practice to checkin more fine-grained changes. Maybe after each implementation of a feature, after fixing a bug (rather than 10 bugs) etc...

Posts you might also be interested in..

Credits: Hoctro | Jack Book

0 Comments:

Post a Comment