Posts Tagged ‘version control’

Code Kata Reporting Tool

// August 3rd, 2012 // No Comments » // Agile, Tools

Code Katas are so useful we wanted to analyze, share, and relive the infamous experience. Code katas are a core training practice for software development that I believe heavily in.  To read more about what they are and a list of good ones to practice see my Dojo Code Katas post. Here I want to discuss a script I have been working on to relive the kata step by step.

How We Got Here

We have been doing monthly Randoris at work and we have been including committing to mercurial as part of our practice.  Every refactor and every test/passing code pair we commit.  This helps us practice committing often, a key rule to distributed version control, and writing better commit messages.  This also allows us to relive the commits of each step/person as we rotate through the group. But there was no way to take those commits/diffs and output a useful report to quickly relive it.

What We Wanted

We wanted to be able to post the output back to our confluence wiki for a few reason.  We wanted to be able to analyze where we went right and where we went wrong.  We wanted others who couldn’t participate to be able to relive it as if they were there.  We wanted different teams to be able to see how the same problem is solved by each other and note the subtle differences everyone has and some tricks that certain teams do vs others. Who knows of all the great possibilities, but an open source code kata repo wasn’t good enough. It had to be fast to view, easy to get to, and easy to analyze.
(more…)

One Project One Repository: Mercurial Used Right

// March 14th, 2011 // 7 Comments » // Tools

Mercurial LogoThis is to help those of you transitioning to Mercurial understand the right way to use it, before someone taints your innocent minds. I was recently apart of a transition from CVS to Mercurial where the Change Management (CM) department was very much involved with the switch. The early game plan was to group projects related to each other into the same repository. This was to help CM manage their builds easier, and nearly convinced everyone else that this made sense. Sadly enough it was difficult to convince CM otherwise and there still exists friction on the subject whenever new projects are transitioned. The following are some counter arguments for you to use when trying to explain to your build team to use Mercurial as intended. (more…)