tags:

views:

196

answers:

7

I am new to subversion and am wondering how do you move from develoment to staging then production?

I think I grasp the concept of creating branches made for releases as detailed here. But how do I actually deploy the branch?

Ideally I could just set up a new website and copy the files over from the branch, but I am concerned about copying any svn bindings into production.

If it is pertinent, this is a Visual Studio website project and I am using VisualSVN server, TortoiseSVN and Ankh to integrate with Visual Studio.

A: 

You need some sort of 'deploy' target in your build system that ignores folders named .svn - thats where all of the subversion info lives.

Shane C. Mason
+8  A: 

svn export

Exports the files excluding all the subversion cruft

John Weldon
+3  A: 

You want to do a svn export. this will export the code without the .svn directories all over the place.

Byron Whitlock
+3  A: 

It sounds like you will want to do a SVN Export of the "release" branch. See the Subversion Book's Export documentation for details.

Richard J Foster
+3  A: 

Unless you'll be developing on separate branches, I would just use a tag to mark a release.

You'll then want to do an svn export of that tag, so that you don't have all the extra .svn folders all over.

Ben S
+5  A: 

You're missing a piece here, basically - you shouldn't use subversion alone to deploy to test and production. Your best bet is to use some sort of script which will pull the build from subversion (if use svn export, it won't bring along subversion file hooks), build any necessary files (using MSBuild, which can be scripted), remove the unecessary files (such as .aspx.cs files since you've built the thing), and copy it over to your environment.

Locally, we use powershell to glue everything together and a combination of the svn command line, MSBuild, and nUnit from the command line to do our builds.

John Christensen
Excellent point John - Unless it's a very simple setup, there is likely to be more than just a simple "export" required. In addition to the "pull" type operation you describe (where the script triggers the svn export), I have also seen a "deploy" script placed in the repository. I.e. the process to update is 1) perform the export. 2) Run the deploy script (which typically operates in an interactive mode). In one case, it was actually a "deploy" page.
Richard J Foster
That is a good point, but this actually is a simple setup. so no need to make things overly complex.
Jim
A: 

The way I handle it is I use a build tool (such as ant+ivy or maven) to automate the process of checking the code out of subversion, build a artifact, and then deploy to wherever needed.

I work more on java side, so not familiar with .net tools, perhaps you can use nmaven?

Dave Paroulek