DotNetNuke and Subversion guidelines

Question

I've Googled, Binged, and here at StackOverflow, looked through the related questions and searched, but I'm not finding what I'm looking for. I've also searched documentation on DNN.

What I'm looking for is any guidance (tutorials, blogs, step-by-step instructions for setting up a repository) etc from people who are experienced in using DotNetNuke with SVN.

We use SVN for all our source control, and have no problem with standard applications, because we pretty much built the repository and directory structure to work with our processes. This means when we do web sites, in Visual Studio, we do file based web sites, rather than setting them up in the local IIS. It just makes things easier for us.

However, with DNN, it appears that even if you get the source code, it is expecting to be set up in the local IIS, which means additional headaches for us.

For example, we are moving all of our source code off our local C drives, and onto a shared drive on a server. This is to enable backups in addition to our normal source control. (This was a management decision). So that means that we need to change the virtual web app when we make the move.

Has anyone come up with a good way to work around this? Can DNN be set up so that the developer web server in Visual Studio can be used, so that we can treat it just like any normal web app? Am I missing something obvious?

Answer 1

Source Control

I recommend using separate projects for DotNetNuke projects (skins, modules, providers), and not checking the actual web site itself into source control environment (DNN Modules would use the WAP style project). Each developer could then have their own DotnetNuke site and database in their development environment. I also don't recommend making changes to DotNetNuke's core so that you have a clean upgrade path. I would recommend using a tool such as Red Gate's SQL Data Compare in order to generate database scripts for your data that you could keep in the source control environment as well.

Here is some more information about setting up a Web Application Project for a DotNetNuke module.

Testing/Staging/Production

Keeping these separate in DotNetNuke is generally very easy because you're already creating modules that plug into a DNN site. My recommendation is to create packaged and properly versioned modules so that you can cleanly install them on test, staging, and production.

Here is some information on using NAnt to automate DNN module packaging.