One of the features I remember using in Visual Source Safe was the ability to put in custom keywords within my comments that would automatically be updated each time I did a check-in. I thought this feature was not available in Subversion, but I was wrong!  Subversion uses Properties!

Subversion Properties

One of the features of Subversion is the ability to add your own Metadata to a file that goes along with the file each time it’s committed. Metadata can be changed for each commit and works the same way when your source code or document is committed.  Subversion provides it’s own set of properties.  One of the properties is  svn:keywords.

svn:keywords Property

svn:keywords property allows specific keywords to be replaced when ever commit to file happens.  This is great for leaving comments in your code that are updated each time a commit is done.  In our latest project we want to update the Author, the Revision Number and the URL (Branch, Trunk or Tag) on each committed.  This gives us a quick status of who last updated the file, what revision number was and where in the Repository.  Thinking now, we should add the date as well.

So how do you set SVN Properties?

There is a couple of ways. One way is to go into the config file on the server where the repository is located and make the pattern change there to use it. So each time a file of that pattern is added to the repository the svn:keywords property is added. By default this is turned off.

The other way is add the property to each file through TortoiseSVN.  This can be a pain if you have several files to do, but if you select all your files in your workspace, and then select the properties of the files, you are able to recursively add the property. However the drawback to this is that you need to add the property to any new files that you add to the repository.  Sometimes you don’t have access to the repository config file so this is the only way to do then.

Once you’ve selected the properties of the file(s), you’ll see Subversion tab within the file’s property sheet. Select the tab and click the Properties… button.

A property window opens where you can edit or select a new property for the file(s).

Here I have already set up the svn:keywords.  I have decided that for this file the only three (3) keyword values to replace are Author, URL and Rev.  If I wanted to add/remove values, highlight the Property and click the Edit.. button.

I can then add or remove the property values.  Currently there are five (5) values that svn:keywords will search and replace.

Author: The developer who last committed

Rev: The revision number when last committed

Date: The Date of when it was committed.

URL: the full URL to the latest version of the file in the repository.

Id: A combination of Author, Rev and Date

Once the keyword values for the svn:keywords property has been set to the file(s), subversion will look for these keywords and replace them with the information from the repository each time a commit happens.

Adding the Comment in your code that will be replaced by the svn:keywords

I’m doing this in C# but it really does not matter what programming language or file you are adding these keywords to.  As long as it starts and ends with a $

In mode code I added the following 2 comment lines (It could have also been on the same line)

Here you see I have // $Author$ , //$Rev$ and //$URL$

Now if I commit the file the keywords will be replaced with the following information:

The SVN Commit replaced the $Author$ with $Author: nhansen$.  If the next time someone else on the team commits the change, their name will show up here.

You can see that the revision number has jumped to 1290 when I commit some changes. (Several commits happened between when I first started working on this blog post)

This is a very cool feature of Subversion that happens to be hidden to most developers.  Many don’t even realize that they have this option available to them.  At Venice Consulting Group, we’ve begun using these new features on a few projects and I can say this has been a very positive experience so far.

If you have any other way of using the Subversion property feature, I’d love to hear them. Please add them to the comments section.

of those cool applications that I’ve found on the internet is a product call Commit Monitor.  It’s a great little tool that runs inside your task tray for Windows.  When ever a commit has happened you’ll be notified (based on the time you set to check the Repository)

This is very helpful for me as the CTO to know that the teams are actually committing their work and I can review each project without having to get a local copy on my machine.  This is also VERY helpful when your on a time and need to know if others on the team have committed any new changes that you may need to get to keep current.

Here is a screen shot of what it looks like. This is snapshot of one of our Servers that contains the current active projects we have going on at the time.  I have blacked out the names of the projects to protect the innocent.

This is the main screen for the application. On the left you can see all the repositories from a specific server. If you had other projects your working on from different servers, you could also add them there too. I have not seen a limation.  On the right pane, you have all the revisions, the date and the author of who checked in.

If you needed to get a diff on a what has changed, its just as easy as selecting the two revisions in the repository and clicking the show Diff.  If you have a specific Diff Program you like to use, simply select it in the options area of the application and it will use that tool.

When the application goes and checks to see if a anything is commited, you will see that that the icon on the tray is animating. (if you don’t like the animation you can also turn this off too.)

If you happen to be at the computer when the commit has changed, you’ll also hear a sound (same one as exchange so I had to change it because I thought I was getting email) and a message alert telling you the project, how many commits since you last checked the main screen for that repository, and the author who made the change.

To view the changes double click on the icon in the tray.  It will bring up the window that shows you all the projects your monitoring and any new updates since you last checked will be in bold with a number in parentheses telling you how many commits.

So that’s Commit Monitor in a nut shell. If think this tool would be as valuable as I have, download it and donate some money to the developer. I gave some money so if everyone did, we can support him to continue to make great tools like this one!

Many of you may or may not know that for the last year I’ve been deep into product development instead of my normal role of consulting. (My company continues to offer consulting services and we’ve grown to over 40 employees! ) Our growth has allowed the company to invest my time and company capital into a product that I’ve wanted to develop for years. We plan on releasing a beta in the first quarter of ‘08.

We started with a hybrid approach of partial specifications and some form of agile development.The one thing that I’ve noticed is that this has put some stress on the development team. The traditional way of developing for a client was just not working. I wanted an Agile approach but I’ve had to re educate the development team. I believe they have been so used to the process of having everything handed to them in the spec, that they’ve lost the ability to be agile. We don’t want to be cowboys but I’m too strong a believer that “too much process” can hinder progress. However, I do have other senior executives that may think otherwise.
(That’s a different post. that I have to do someday.)

Our product process has begun to evolve into the scrum methodology before I even knew it existed. It really started back in May. We needed to demo what we had so far for at the BI Conference. The entire team went into a sprint to get specific features completed. We were able to complete the task and had a successful show at the Conference.We went back to developing normally for a few months but I was feeling it was probably taking a bit longer than I would have liked.

Then we had another conference in September and the sprint began again! These sprints seemed to have produced the best results. The one thing that we could improve upon is the hours. We need to have the same passion but get the guys only working a regular shift.I know sometimes the development team feels frustrated, but I 100% strongly believe that these sprints to show where we are, even if things are not completed, has proven certain things definitely work and other components we thought would, don’t. I know some felt rushed and missed a few thing but that’s what re-factoring is for. To me, prove the idea can work and then tighten it up! Re-factor and unit Test it to death!Over the last month, I’ve talked to a couple of my friends who are working for new startups and the one methodology that has been brought up in the conversations more than a few times was the Scrum methodology that they adopted from the beginning!

Why the word Scrum?It comes from the fact of having a small team (like Rugby). In Rugby (which I played in High School in Canada), you have a scrum to determine which team gets the ball.Everyone works together by huddling in a circle and under the scrum a player called the hooker (which I played) would try to get the ball as the team used their feet to hook the ball back.So the term scrum is perfect because everyone is working together to complete a specific task.Everyone has their role. In sports you’re constantly having to adjust your game plan and be agile enough to change it when need be. Why should software development be any different?

Scrum works for small teams around 5 to 9 members (perfect I have 4 developers and myself), usually has involvement from the client (again perfect because our partner is actively involved), and outside consultant to help once in a while (perfect, we’re bringing help from an expert one to two days a weeks, when needed, to help maximize productivity).

Characteristics of Scrum

• A brief daily meeting , at which progress is explained, upcoming work is described and any issues/concerns are raised.
• A product backlog of prioritized work to be done.
• Completion of a fixed set of backlog items in a series of short iterations or sprints.
• A brief sprint planning session in which the backlog items for the sprint will be defined. (Mini Specs)
• A brief sprint retrospective, at which all team members reflect about the past sprint.

Last week I decided to have a daily meeting with the team to see how things are going and what we need to do next. I called it the 10 at 10. (A call at 10 for 10 minutes). We also setup a new tool called Trac that completely integrates with Subversion and includes milestones, and tickets that can be used to set up tasks. This is going to be great because now we’ve set tasks for people to complete for a specific period of time.