Serious Samurize Desktop Example

This was pretty straightforward to implement in Samurize.
1. Open your Samurize Config Editor.

Serious Samurize Config

2. Add a new meter, and select console meter (tutorial)
3. In the meter config tool bar on the right, select the source tab.
4. This requires the SVN command line application application installed (available here)
5. Enter the source to be this command:

svn log https://nant.svn.sourceforge.net/svnroot/nant -l 10

This is an example URL from Nhibernate’s SVN Repository
Note: You may need provide a path to the svn command.

view of the widget

This will return the last ten entries as a command line entries as a Samurize meter.
Simple way create a cool little desktop control displaying information that is relevant to a developer.

Quick Links:

Serious Samurize
http://www.samurize.com

Lifehacker
http://lifehacker.com/

Subversion
http://subversion.tigris.org

Bookmark It

This strategy is different than many other “development” strategies, because it never defines what you develop, how you develop, or even how you manage a project. The only focus of this strategy is committing atomic changes, and logging those changes in the commit comments properly, and finally only commit code that builds. Using version control in this fashion produces a usable change log that can be used to track progress between revisions.

Commit only one change a time. We should only commit one atomic feature, fix, update at a time. If you have 12 bug fixes in the queue, every bug fix should be a commit. If you have a new feature such as a new management screen, it would need to be broken in to it’s basic parts. New data access code, updated business logic, new ui screen, new ui code, etc.

Commit only working code. This is a no brainier, commit only code that builds, and does not error when you go to it. If you need to commit code that breaks, comment it out. If it’s such a major change it will break the build, then you need to branch. This keeps the integrity of build, and the project’s trunk intact.

Comment your changes effectively. Commit log comments are not useful unless they communicate something quicker, and more effective than looking at the file log. I should be able to look at the commit log, and see what sections were touched in less than 15 words. In earlier posts I outlined a strategy for useable subversion comments, so I won’t digress.

Using this strategy has made me a more effective developer, by addressing some of my weaknesses. If you are not thinking about source control in terms of development strategy you may be under utilizing the the tool. Instead of searching for the next new tool, we should look at what we already have, and how to use those more efficiently.

Bookmark It