Ever since I first came across the original XMod I have struggled to manage my code. I tried to get into the habit of constantly backing up my DotNetNuke (DNN) database and files but this was never a substitute for version control. I also made regular copies of the code while I was working on it by copying and pasting it into Notepad++ on my desktop. But this was never satisfactory either. Time consuming and unmanageable.

It was only recently, when I joined a team that was using Subversion for code version control, that I wondered what I’d been playing at all these years. If you’re not familiar with Subversion, I suggest you take a look at it right now. You can sign up for a free account right here. Subversion is a brilliant Open Source version control system that’s easy to use and very powerful.

The last time I used version control in a professional environment was in the late '90’s when I was a lead developer in small team building an image library system for a publishing company using VB6. We use Visual SourceSafe and it worked pretty well for us. But we were hamstrung because each person had to lock the files that they checked out. It was fine when we were working on separate modules but, when our work overlapped and two or more of us required regular access to certain classes, it was less than efficient.

In comparison, Subversion is streets ahead and once you start to use it you will not be happy coding without it. This evening, I decided to try and add my XMod Pro forms and templates to Subversion and I was pleased to find that it worked just fine.

What do you need to get started?

Well, firstly you need a Subversion repository set up and once you have this, I believe that the best way to start working is to get a copy of TortoiseSVN which is a windows client (also Open Source) that takes all the pain out of using Subversion. TortoiseSVN integrates beautifully with Windows Explorer and provides all the Subversion commands under the explorer menu when you right click on files and folders. There’s even a tool to integrate it with Visual Studio.

So, once you are set up you can import your XMod Pro templates and forms into your Subversion repository.

I suggest creating a directory in your repository called something like work\ProjectName\XmodPro\trunk. It is unlikely that you will be branching and merging and making full use of the power of Subversion for your XMod Pro projects, but you should try to follow best practices and put the main code in a folder called ‘trunk’.

I can recommend the following book on Subversion if you would like to learn more.

Pragmatic Version Control: Using Subversion (The Pragmatic Starter Kit Series)(2nd Edition)

So, I imported the directory that XMod Pro uses to store forms and templates into my Subversion repository. You will find this in your DotNetNuke installation, which in this case is on my local machine at C:\inetpub\dotnetnuke5\Portals\_default\XmodPro.

You will then have a working copy of your XMod Pro forms and templates and Subversion will manage all the changes you make to them.

Of course, it’s not as simple as that

Subversion cannot read your mind so you will have to add any new templates and forms to the repository after you have created them and you will need to commit your changes regularly in order that you may roll back to an earlier revision in the event of any mishap.

In this image you can see that TortoiseSVN uses icon overlays to show that these XMod Pro files are being managed by Subversion and are all up to date.

Once you edit a template in XMod Pro, you will notice that these icons change to red exclamation marks. This is to remind you to commit them.

As a test, I edited the template “portalalias” and changed the pager’s pagesize parameter. I then committed this change to Subversion and was able to see the revisions in the log. By highlighting the two versions, I could ‘show differences’ and view what I had changed.

I was then able to roll back to the version before I changed the page size. This is great news as I was finding that often during development, I would make some changes but want to save the code as it was before I made another change. Or, from time to time, something I did was causing a problem in a form and the form would no longer load. There are also many occasions where I am working on a project with a designer who is not familiar with XMod Pro or may be trying to add some complex javascript to a form. It is very useful in these circumstances to keep track of everything that is being done and to be able to roll back to a working version if the designer accidentally breaks the code and doesn’t understand how to fix it.

Of course, all this means that access is required to the disk where the DotNetNuke installation resides, and for this, your hosting provider must allow remote desktop access. But, if you are serious about your development and prefer not to lose code then this shouldn’t be an issue.