Strong opinions, weakly held

Tag: version control

Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd.

Linus Torvalds, by way of Typical Programmer. Satire, of course.

Bad drug interactions

As a software developer, I love version control, and I love bug tracking systems. I honestly don’t know how anyone got any work done without them. I’ve got Subversion set up with a post-commit hook that reports my commits to FogBugz. This enables FogBugz to keep track of which code changes are associated with each issue. If, a year from now, I want to go back and see exactly which changes I made to fix a certain bug, FogBugz has that information. It’s really cool.

But, as usual, there’s a catch. I also use svnmerge to keep track of changes between branches. It makes it trivial to merge changes from the trunk to a release branch, or vice versa. When you merge changes from one branch to another, svnmerge makes a nice file with the descriptions of each change included in that merge so that you can use it as the log message when you commit the changes associated with the merge.

What I’ve just realized is that my post-commit hook is finding all the references to bugs in that message and updating each of the bugs in FogBugz with a link to the commit associated with the merge. This has two effects. One, it causes the commit to take a really, really long time. (The post-commit script calls FogBugz once for every bug reference in the commit message.) And the other is that now every bug referenced in the merge is going to have a link to this giant commit that’s not really associated with any of them.

Sometimes all of your brilliant individual ideas combine to produce a bad outcome. In the future I won’t be using the commit message that svnmerge provides.

Analyzing Git

Evaluating tools is sort of like judging art. The two questions you should have about a work of art are, “Do I like it?” and “Is it important?” They’re completely separate. You may not enjoy the music of The Beatles, but that doesn’t change the fact that they were hugely important in the evolution of popular music.

When I’m looking at tools, I try to keep both of those questions in mind. I don’t care for Enterprise Java Beans, but it was important for me to know what they’re used for and why they’re important. Git, the distributed version control application, has been getting a lot of attention lately. I haven’t had a chance to take much of a look at it myself, and I’ve been wondering whether I would like using it. The excess hype has awakened my inner skeptic, but I’m still very curious.

In the meantime, Ryan Tomayko has written an outstanding piece of analysis that answers both my questions. It explains why developers might enjoy using Git, and its significance. What’s important about Git is that it allows you to adapt your version control usage to your working style rather than adapting your work style to Subversion or whatever system you use, in that it allows you to manage exactly which changes you check in at any time, including multiple changes to a single file. Ryan explains how this works by describing the “Tangled Working Copy” problem and how you go about solving it in Subversion and Git.

I never run into Ryan’s “Tangled Working Copy” problem because I have adapted myself to be a creature of Subversion. I am always very mindful of what’s in the current change list and when I want to commit it. But I shouldn’t have to work that way, and it’s very cool that Git lets you escape that model. It seems that’s the important thing about Git.

I wanted to flag Ryan’s article not just because it demystifies some of the Git hype for those of us who are still using Subversion, but also because it represents what blog posts that purport to provide analysis should aspire to.

© 2024 rc3.org

Theme by Anders NorenUp ↑