Most software developers will understand the importance of version control systems. Having a complete history of software source code with frequent snapshots allows developers to see how the code evolved over time and see who changed what, when and hopefully (with useful check-in/commit messages!) why. This information is invaluable to both new developers joining a project and to anyone already involved in a project when extending the software or fixing bugs.
There is a variety of different version control system available, with a huge range of features and functionality, but most follow a similar core model:
In the past I’ve worked in a team where Subversion was the version control system of choice. The team followed a fairly disciplined Agile approach and operated in a highly collaborative manner. Ownership and responsibility of all the code was very much shared across the team. In this environment it was important to keep up with the development of the entire code base; support duties were rotated and the goal was for anybody to be able to investigate issues in any area of the system.
There are a number of great tools built around Subversion, and one of the tools we used was an application called CommitMonitor.
CommitMonitor is a small tool to monitor Apache™ Subversion® repositories for new commits. It has a very small memory footprint and resides in the system tray.
CommitMonitor allows developers to follow the changes to a Subversion repository. The user can add a “project” by supplying a Subversion repository URL and the application then polls the repository for commits at frequent intervals. Commits are displayed in a grid view showing revision, date, author and log message. The paths of files changed in the commit are also displayed and the user is notified via a “toast” panel when new commits are detected.
I now work in a team where Perforce and Team Foundation Server 2010 are both used to provide version control. Upon moving I immediately missed the functionality offered by CommitMonitor and couldn’t find a tool providing a similar repository change tracking ability. Partly as a learning experience and partly to fill a gap in my tool-set I created SourceLog.
SourceLog is heavily inspired by CommitMonitor – it serves a common purpose and provides a very similar feature set. However the aim of SourceLog is to bring this functionality to multiple version control systems where developers can track any number of repositories across different version control systems and receive notifications from and view changes in the same application.
SourceLog displays not only a list of changed files associated with each change/commit, but also displays the file differences side by side within the main window so that the user can quickly get a very detailed understanding of what has changed.
Notifications are displayed in a “toast” panel like this:
SourceLog has been partly about providing a useful tool and partly a personal learning experience. Built using Windows Presentation Foundation, the aim is to follow the Model-View-ViewModel pattern. The core model is described in the SourceLog.Model project and is designed as follows:
The Views and ViewModels are stored in the SourceLog.UI project. Each plugin has a separate project in the solution and each plugin project has a post-build event command to copy the output assembly to the Plugins directory of the UI project. This command also copies any additional assemblies required by the plugin. For example, for the GitHub plugin:
mkdir "$(SolutionDir)SourceLog.UI\Plugins\$(TargetName)" copy /Y "$(TargetDir)$(TargetFileName)" "$(SolutionDir)SourceLog.UI\Plugins\$(TargetName)" copy /Y "$(TargetDir)Newtonsoft.Json.dll" "$(SolutionDir)SourceLog.UI\Plugins\$(TargetName)"
The UI project is then configured to publish a ClickOnce installation package including the plugins and all dependencies.
The solution also contains an ASP.NET web application project. This is to enable the ClickOnce installer to be hosted on AppHarbor. This was configured using the following steps:
- Create an AppHarbor account and ensure you’re using a Web Worker process.
- Create an AppHarbor application and connect it to your GitHub repository.
- Copy the v7.0A Windows SDK folder (C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A) to a Lib folder alongside the solution.
- Open the WPF csproj file (in this case SourceLog.UI.csproj) in a text editor such as Notepad++
- Modify the DefaultTargets attribute on the Project element to Publish.
- Set the PublishDir property to $(OutDir)\_PublishedWebsites\ClickOnceHostWeb.
- Set the UpdateUrl property to http://sourcelog.apphb.com/.
- Set the following additional properties
<GenerateBootstrapperSdkPath>$(MSBuildProjectDirectory)\..\Lib\Microsoft SDKs\Windows\v7.0A\Bootstrapper</GenerateBootstrapperSdkPath> <SdkToolsPath>$(MSBuildProjectDirectory)\..\Lib\Microsoft SDKs\Windows\v7.0A\Bin</SdkToolsPath>
The application is packaged into a ClickOnce installer and this is available to download from the AppHarbor host page: http://sourcelog.apphb.com/
The project is open source and is hosted on GitHub here: https://github.com/tomhunter-gh/SourceLog
So far I’ve only been able to test the application in a limited number of environments and I would be very keen to hear if others have been able to get the application up and running and if not what problems have been encountered.
Additionally, feedback and suggestions are very much welcome and I would be particularly keen to get input on the following areas:
- The idea as a whole
- The GitHub project page / AppHarbor host page
- The install experience
- The features/functionality of the application
- The design/architecture of the application
- The coding style and conventions/consistency
- Anything else..
I would also be very happy to collaborate with others on further development of the application, so if this is something you’d be interested in, please drop me a line!