SCM

I started working for a new group around mid-September and inherited an old (5 years or so) shell-script build system. Most of it is in KSH (I really prefer BASH) but alot of it is so poorly written and thought out that I have a hell of a time trying to fix/enhance it. Every time I need to do something to the scripts I oscillate for an hour on whether I should try to work my change into the existing script or just take the time to re-write the whole thing!

I was Googling today for some thoughts about writing shell scripts and found a great article about writing robust bash shell scripts. While I don't use everything mentioned in the article, I was happily surprised to find that I do use more than a couple of them.

Of course, one reason for my irritation with the system I've inherited is that it doesn't use any. Before working in this group, all SCM infrastructure I'd done was built ground up by myself. I feel for those poor developers that get stuck trying to enhance old code now that I've really gotten a taste of how hard it can be. I imagine there is alot more nasty build system scripts out there than there are good ones but I'll certainly try to even the odds a bit by making my scripts as robust, readable and commented as possible.

Hopefully someone who comes three or four years after I'm one will be pleasantly surprised when they have to add something to my scripts!

Today I had a developer who wanted to change his commit message after he'd already made the commit to the Subversion repository. Initially, I told him it wasn't possible, but then I decided I should check if my assertion was correct. It wasn't...

To change/edit a Subversion commit message after the commit, do the following on the Subversion server:



The --bypass-hooks argument is necessary because you are editing a non-versioned property of the revision. As such, you lose the history of the original commit message so Subversion requires the pre-revprop-change hook to be enabled. Passing --bypass-hooks bypasses this requirement and allows the change.

It's become time again for me to revisit my organization's desire to move from CVS to Subversion. I've gotten out a few releases of our products recently and with that work out of the way, I'm getting back to swimming around in Subversion.

This is the third installment in my ongoing detail of the move to Subversion. In the first installment of this series, I spoke about my organization's interest in using Subversion instead of CVS. In the second installment, I detailed how I installed Subversion on Mac OS X (Panther) and how I initiated the process of converting some of our CVS repositories. In this installment, I will go into further detail about interacting with the "mock" Subversion server and the pilot project repositories.

Continue reading "Moving from CVS to SVN - Swimming Around" »

Lately I've been working very hard to increase my knowledge and understanding of my new role at work (Software Configuration Management Engineer - SCM). I am the only SCM for two products and a total of ten developers (though I support around 20 people between the two teams in total).

Both development teams loosely base their process in the Agile style of Extreme Programming. I have found a few resources that seem to be quite good for information on my position and role.

CM Crossroads is an online community and resource center for configuration management. The have a wealth of information at their site and they do a good job of recommending books, best practices, and software to make my job easier and the development teams more productive.

I'll be detailing things I learn here in a new category: "SCM" under the category "Work".

I started the process to convert our organization's CVS repository to Subversion. I decided to do a mock implementation as my "pilot". I took the CVS repository and made a copy to another machine (Mac OS X 10.3.7) which serves as the "mock" Subversion server.

Our current CVS repository consists of two "major" projects and 26 small projects (support pieces, tools, scripts, etc). I decided to try to convert one of the major projects to start with.

Continue reading "Moving from CVS to SVN - Diving In" »