Minimum SVN Log Message Length

Update 2010-04-07: Stefan Küng, TortoiseSVN lead developer, commented that you can simply set the tsvn:logminsize property on your folders and the commit button in TortoiseSVN will be disabled until the log message contains at least as many characters as the value of the property.

While working on the Stars-Nova project at SourceForge.net we wanted to prevent developers from accidentally making commits to Subversion (SVN) without providing a log message. Sometimes developers simply forget to enter a log message, leaving the rest of the team in the dark as to what changes they have made to the repository. You can diff the modified files to try to figure out what they have done, but a short message in the revision log would save you that time. Even experienced developers might on occasion slip and commit with an empty message. Luckily SF.net allows you to correct the log message after the commit has been made (command line: svn propset svn:log "new log message" -r80 --revprop <repository URL>), but that might not be the case for your choice of SVN hosting provider. It might take a while before the developer who forgot to enter the message is made aware of the issue and can correct it so we would rather get the commit right the first time around and save us the trouble.

SVN allows arbitrary server-side scripts to be configured to run on various events (pre-commit, post-commit, etc.). These script hooks offer a lot of flexibility and would have been a good place to centrally enforce a non-empty log message policy. However, because of security reasons SF.net, and all other SVN hosting providers I know of, does not allow user-defined server-side hook scripts. Instead SF.net provides a short list of predefined scripts and a check on log message length is not among the scripts that are included. I have submitted a feature request at SF.net suggesting that they add a server-side hook script such as this and I encourage you to vote for it.

Most of the developers on Stars-Nova use TortoiseSVN and this SVN client just happens to support client-side hook scripts. Based on that I wrote a small script (mmm… JScript) that prevents the user from accidentally executing a commit without providing a message. Currently it does not trim leading and trailing spaces, new lines or other non-printable characters before the character count is checked. However, the minimum character count can be configured so that an accidental space or new line (new lines are composed of two characters: carriage return and line feed) will also stop the commit.

Usage:

  1. Make sure you have a recent version of TortoiseSVN (min. v1.5).
  2. Open the TortoiseSVN Settings dialog (right-click a folder in Windows Explorer > TortoiseSVN > Settings).
  3. Go to “Hook Scripts” and click “Add…”.
  4. Choose Hook Type: Pre-Commit Hook
  5. Set the Working Copy Path to the directory (or any parent directory) where you checked out your working copy from SVN. “C:\” works as well if you want this script to always execute when you run commit on working copies located anywhere on your C drive.
  6. Set Command Line To Execute: WScript <path to script>\MinMessageLength.js
  7. Ensure that “Wait for script to finish” is checked.
  8. Ensure that “Hide the script while running” is checked.
  9. (Optional) Configure the minimum number of characters allowed by changing  the MIN_CHARACTERS variable in the script.

Download the TortoiseSVN client-side hook script

Sun SPOT

Sun Microsystems released their Small Programmable Object Technology (SPOT) as open source earlier this year. SPOT fits in the same category as the Bug Labs BUG that I’ve previously blogged about. SPOT seems to be less modular than the BUG. Both platforms are Java based (SPOT is J2ME) and they also feature some of the same type of hardware. The Sun SPOT device measures 70 x 41 x 23 mm and contains features the following hardware sweetness:

  • IEEE 802.15.4 (forms the basis for ZigBee) with integrated antenna
  • 3-axis accelerometer (with two range settings: 2G or 6G)
  • Temperature sensor
  • Light sensor
  • Tri-color LEDs
  • 6 analog inputs readable by an ADC
  • 2 momentary switches
  • 5 general purpose I/O pins and 4 high current output pins

SPOT’s main advantage over the BUG is that it has built-in communication. Bug Labs are probably hard at work to build a communication module as well to make it more desirable.

Edit (2008-07-19): Clarified the relation between IEEE 802.15.4 and ZigBee.

Lego bug

Bug Labs has developed a modular mini-computer running on open source software. I first read about it in the O’Reilly Radar blog. Bug Labs has promised to make all the source code for the platform available. The main BUGbase module is 10×5 cm big and can accommodate four other modules, each 5×5 cm big.

The system isn’t completely finished, but soon it will be possible to buy the base module and other modules like:

  • BUGlocate – GPS receiver.
  • BUGcam2MP – 2 megapixel digital camera.
  • BUGview – 2.46″ 320×240 pixels LCD screen.
  • BUGmotion – A combined motion detector and accelerometer.

The base module will eventually have built-in WiFi and hopefully they will also make a UMTS (3G) communication module. Applications are developed using Java together with an Eclipse based IDE. I’m very interested to see what kind of applications people might come up with for this thing.

It’s like Lego for grownups.

Slow

This was a slow week. I didn’t get much done in terms of programming and I also took a short vacation a couple of days to clear my head.

Some late breaking news about Android: Google Android phones make debut.

Estimated time used for the project the past week: 30 hours

The Java Magical Service

JMS is like a magical service. Inject a message about a certain topic into a JMS system and other people, who are interested in the same topic, can read the message as well. Maybe not too much magic, but it does work. JMS has basically two types of message channels:

  • Topics – used by publish/subscribe (pub/sub) where the communication can be many-to-many.
  • Queues – used for point-to-point communication.

In both cases the sender and receiver can be decoupled in terms of both space, time and synchronization as described by Eugster et al. in The Many Faces of Publish/Subscribe. JMS also has a hierarchical topic-based publish/subscribe model which is easy to get into. I’ve been working with Apache MQ to implement a simple JMS based publish/subscribe system. The server part of the system is almost functional, but I haven’t started on the mobile client code yet. I’m not quite satisfied with the way the server system processes all the incoming events because the business logic is spread out into several listener classes. My current goal is to find a more convenient way to arrange the logic so that it will be easier to set different policies for the system. I’ll also start writing some code for Android and find out how easy it is to get Android to talk to a JMS based system. Maybe I’ll have to use one of the alternative transports that Apache MQ provides to make it easier.

I’ve done some checking on IEEE 802.1Q and 802.1p (which is rumored to be defined in 802.1G) in regards to the router that might be used in a practical implementation of this system. 802.1p is essentially a standard for providing QoS at the MAC level. It defines eight different traffic classes which are used by 802.1Q. 802.1Q is the Virtual Bridged Local Area Networks (VLAN) standard. In this standard the IEEE has defined a framework called the Generic Attribute Registration Protocol (GARP) for switches and bridges to work with different types of attribute values. GARP is in turn used by a VLAN management protocol called GARP VLAN Registration Protocol (GVRP) which enables you to manage how VLAN configurations are propagated throughout a network of switches (Cisco has a similar proprietary protocol called VTP).

What seems to be the case is that GVRP can only be used to manage switches when there are several connected in a network. According to this article by HP it looks like the first switch must be manually configured. I’m not entirely sure about the technical details, but from what I can tell it doesn’t seem to align with our needs of just configuring one switch and getting it to forward Internet traffic.

Estimated time used for the project the past week: 40 hours

Progress report for the past week

I’ve read a lot about about messaging systems, JMS and how they relate to publish-subscribe, but I think I need to start programming to get a feel for what it really is about. The Enterprise Integration Patterns book that I’m borrowing has kept me busy most of the week. I’ve also drawn a few other models for the system with different level of abstraction. You can view the new models in this PDF: Location-based event system models.

I’ve checked out Apache MQ and is seems like something I can use. It supports lots of different transport protocols for message exchange and the configuration doesn’t seem to be too tricky. It also supports JMS 1.1 which is the latest version of JMS. I also tested Git a bit and I’ve decided to start using it on this project. At the surface it doesn’t seem to be very much different from Subversion, which I’m used to, but the fact that you can commit to a local repository/index is a big bonus. I look forward to explore the distributed features in Git.

Estimated time used for the project the past week: 38 hours

Progress report so far

So far I’ve read a lot of literature about location-based/aware systems and also a few things about publish-subscribe based event systems. The architecture of the system I intend to design is shown as part of a set of slided I made a while ago. I found a way to make the architecture more generic by using a publish-subscribe based system on the home server. Check these PDF files for the original and the new slides.

The original slides were based on the assumption that the mobile phone already knew the status of the alarm system. That isn’t very realistic so the new slides makes use of an event driven system (publish-subscribe) to make the phone aware of the alarm system status. The correct order to read the slides would be to first look at the new slides and then the process continues in the original slides.

I’ve also tried out the Android SDK and written a few small applications to understand how it works. Since there might be better mobile phone frameworks/platforms that can be used I’ve also done some research into other related frameworks/platforms. The disadvantage of Android is obviously that it doesn’t have any supported phones on the market yet, but on the other hand it’s a quite powerful platform compared to some of the others which are already in the hands of consumers.

I estimate that I’ve used about 40 hours on the project the last 7 days. It’s probably a bit more than 100 if you count from when I began and till now. I’ve also put together a project plan which is nice to have.