Thursday, May 12, 2005

The revison of "tags" in svn

In svn the idea of tags isn't the same as in CVS. To make a tag you in fact (simplified) make a copy of a revision and place it in the tags folder. This is to make it easy to get a tag as all you would have to do is checkout from the tag directory. But you could just checkout from trunk if you give it the correct revision number. If you have that revision number you can do a lot of interesting things such as determining what has changed sense the last release, see who made the most number of commits, or how many bugs were fixed (according to the svn commit logs). Unfortunately obtaining this revision number isn't that easy as you might think.

If you do svn info on the tagged directory you will find that it isn't the revision that was copied from, but a new revision and it doesn't have any properties. But this at least tells us something that we can use, the revision of the copy.  Using that version number we can get the full log for the copy with "svn log -r $rev -v ...". Note the "-v". If you don't pass -v then you won't see:

Changed paths: A /tags/source/phpquickgallery/phpquickgallery-1.7 (from /trunk/phpquickgallery:99)

Now pass --xml and you can easily and safely parse out the revision of the release (in this case 99). So after all that you finally have the trunk revision. :) The reason I originally wanted this piece of information was so that for my personal projects I could generate my ChangeLog file entirely from my svn commit log. My change log typically would have the exact same comment as my cvs commit log, but sometimes I wouldn't remember to add changes to the ChangeLog. So here is a little script which will generate a ChangeLog for a release

#!/bin/sh -x
# Gets the changes between two releases of an application
set -e


# Grep the version number of the move
rev=`svn info $REP-$VER/ | grep "Last Changed Rev" | sed s/Last\ Changed\ Rev:\ //g`
# Grep the log for the copyfrom revision (which is the real revision that this is taged from)
tag=`svn log -r $rev $REP-$VER -v --xml | grep copyfrom-rev | sed s/.*copyfrom-rev=\"//g | sed s/\"//g`

rev=`svn info $REP-$LASTVER/ | grep "Last Changed Rev" | sed s/Last\ Changed\ Rev:\ //g`
lasttag=`svn log -r $rev $REP-$LASTVER -v --xml | grep copyfrom-rev | sed s/.*copyfrom-rev=\"//g | sed s/\"//g`

# Get the log between the two versions
svn log -r $tag:$lasttag $HOST/trunk/source/$APP --xml > $APP-$VER.changelog.xml

# Grap the messages
# Remove empty lines and Internal messages
cat $APP-$VER.changelog.xml | awk '//,/<\/msg>/' | sed -e s/^\//g | \
sed -e s/\<\\/msg\>\$//g | awk ' !/^[ \t]*$/ { print $0 }' | grep -v Internal | \
awk 'BEGIN{print '$VER'} {print "* "$0}' > $APP-$VER.changelog

Thursday, May 05, 2005

A few good programming books

When I get free time I enjoy reading programming books. I frequently pick up new ones that people recommend to see what they have to offer(1). Here is a list of the best books that I think every serious programmer should read, if not already have sitting on their shelf.

Core Programming

These books don't teach the latest fad programming language in twenty for hours and often times they often don't even discuss a specific programming language, but the techniques that are taught are timeless and when taken to heart no programmer will come out unchanged for the better.
Unlike most programming books each time you read these books you discover something new and valuable. I will typical read them every other year, each time gaining something new as I draw upon my recent experiences. For those who aren't new to programming after reading these books you will wish someone had told you about them back when you were first learning to program. These books each contain wisdom that the authors have learned through the years.

Pragmatic Programmer
Pragmatic Programmer: From Journeyman to Master

By Andrew Hunt, David Thomas

Addison-Wesley, Paperback, Published October 1999, 321 pages, ISBN 020161622X

An overview of all the essential tools (editors, version control systems, project managers, etc) that a programmer should be using. It explains why they should each be used and also how to best use them. This book is clear, concise, and filled with examples. It shows good habits which can form the foundation for success in projects and in a programming career.

Code Complete
Code Complete

By Steve McConnell

Microsoft Press, Paperback, Published March 1993, 857 pages, ISBN 1556154844

An invaluable reference that focuses on successful programming techniques. It includes many examples of good and bad code in many different languages. Topics like: how to make your program easier to debug, naming conventions for variables, comments, and where code should belong in a object, make this book valuable by themselves. But it also covers many other topics in depth like refactoring, design, and testing. This book will bring to light some ugly habits that every programmer has and hopefully rid them of it.

Note that there is a Second Edition (ISBN: 0735619670) which although I haven't read yet I have been told it is similar to the first.

Mythical Man-Month
The Mythical Man-Month

By Frederick P. Brooks Jr.

Addison-Wesley, Paperback, 2nd edition, Published August 1995, 322 pages, ISBN 0201835959

A classic book on software engineering which applies just as much today and when it was written in 1975. The book introduced the idea that changing the size of the staff working on a project wont improve a project, but might in fact significantly hinder it. It also accentuates that there is no silver bullet in programming, only a lot of best practices (see above books). This book is referenced in countless other titles and is a worthy read on its own for the fundamental project management ideas presented.

Diffusion Of Innovations
Diffusion Of Innovations

By: Everett M. Rogers

Free Press; 5th edition (August 16, 2003), 322 pages, ISBN: 0743222091

This book is not the easiest book to read, in fact is reads almost like a text book. If it wasn't populated with short stories all throughout this tomb of a book I would have a hard time recommending it. Countless smaller books have been written based upon the information presented in this book. This book takes you step by step through the diffusion of innovation process. It tells you how each step is reached, and more importantly how it isn't reached. The two books on the upper right The Innovator's Dilemma and Crossing the Chasm discuss specific portions of the curve (begining and end respectivly) and are highly recommended reading also. After reading the book you will find yourself recognizing the adoption curve in your every day life. So why does this go with technical books? Unless you are a code grunt you will want to pursuade a group of people of new ideas (abstract ones at that). This book will help you do just that.

GUI Bloopers
GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers

By Jeff Johnson

Morgan Kaufmann, Paperback, Published March 2000, 559 pages, ISBN 1558605827

What is this book doing here you might ask? Well it might not have the deep insight that the above books have, but it does serves an important purpose. Too many user interface books use confusing abstract themes or waste the majority of the book pointing out stupid interfaces in other applications without providing any content of their own. This book does something different, it goes through all of the common GUI objects (buttons, toolbars, checkbox, etc) and discusses what the widget is suppost to convey to the user, how to use it, and how to not use it. Too many programmers may have read the high level user interface books, but can't apply them to the every day programming. This book plainly lays out what and what not to do, which for a lot of developers is more important than theory.

The Design Of Everyday Things
The Design Of Everyday Things

By Donald A. Norman

Basic Books; 1st Basic edition (September, 2002), 272 pages, ISBN 0465067107

Once you have read GUI Bloopers take the time to check out this book. The vast majority of the book does not talk about computers and there interfaces, but rather much simpler items such as doors and how badly many are designed. More importantly throughout the book the author explains in the most well written manner (don't underestimate this feature) I have read about why designers think their designs are self explanatory when they are just wrong. Most other books gloss over this fact hoping you will memorize their rules. Another idea which is much more prominently talked about in the book is the idea of blocking, or removing features from the users when the option wont do anything or cause harm. Unlike Gui Bloopers, The design Of Everyday Things discusses in more abstract form. Hopefully this will help you make good users interface choices for topics not covered in Gui Bloopers.

1. If you feel there is a book that is on your bookshelf that you think every program should read it let me know about it. Although I listed only a very few books here I have quite a collection at home and at work and have read through many programming books good and bad.


Smada was a project in my Computer Science 4 course at RIT. It was a compiler and simulator. While the design of the code clearly shows that I had not taken a compiler course I am proud of the result. It is clean, had tests, worked and had a very nice debug mode for the compiler. I found it in my backup CD's, cleaned up the code a tiny bit and put the source code up online. It doesn't really have much value and I would create it entirely different today, but it was a neat project.

Wednesday, May 04, 2005


Back when my website had rants (nowadays called a blog) I used a little custom application called websitemaker to insert new rants into the site. I am not sure where the source went, but here is the one screenshot that I found. These days there are much better ways to add a blog to ones website if one desires.


I wrote a fun little applet for KDE called KBinaryClock. It is a panel applet for KDE that displays the current time in binary. The source code for KBinaryClock can be found in the KDE CVS in /kdeaddons/kicker-applets/. It will be released in KDE 3.2 and beyond.

Popular Posts