Question

First, I’m not sure if I should break this question into smaller, individual questions. They’re related, but I’m not sure if I’m doing it wrong. Apologies if I am.

I’m a bit new to the idea of source/version control. I have installed TortoiseSVN on my development laptop, but haven’t really gotten into the habit of using it. That said, I have a live (and embarrassingly small, at the moment) ASP.NET MVC 2 site that will be in need of upgrading soon, and I’m curious as to what the best way to go would be. As an added wrinkle, the site does not currently use a database, but it will relatively soon. I’ve already installed SQL Server 2008 R2 on the server.

So, is there a way for me to use Subversion to push an updated iteration of my site to the server? Or to have the server pull it?

Would it be better to use the version control that comes with VS 2010?

What about the db? When I set up the db and its data in my solution, how would I port that over to the server? Would I have to manually write to the db?

The obvious option is to simply overwrite the existing .dll with the new build and upload new static content, but that seems a bit archaic to me.

Answer 1

You would do better to split this up into multiple questions.

1. Version control – unless you are using a Team Foundation version and have TFS installed, you don’t have version control built into Visual Studio. Subversion is a good choice. I prefer distributed vcs systems like git or hg, but if you’re new to it, svn is a good choice.
2. You can use svn to pull from the server, but you probably don’t want to shove stuff out there directly. If you do, you can automate the step using a build tool like MsBuild, NAnt, Rake, or many others.
3. Database – So far as I know, you’ll need to run your database creation and update scripts on both your local and production machines. You can use the Tasks -> Generate Scripts from your local database to generate the scripts you need to run the first time you set up your production database. After that, you should plan to write and execute update scripts locally and on production. You’ll want to do this to make sure you don’t inadvertently delete data by testing it locally.
4. Archaic or not, xcopy deployment is still viable, especially with a build tool to automate the process.

I hope that helps a bit.