I actually use subversion to update our site at www.mangosteennation.com. I have a folder on the server that is the SVN folder. Then whenever I need to do a deploy to production, I do a get latest on that folder. Then I copy over all of the files from that SVN folder over to the folder that has the live website running in it. It seems to work pretty well. Only thing I never copy is the web.config because it has connection string information in it for our testing database.

We post about something similar.  We are using SVN to deploy our websites and we really like it.

Something bad happen during a deploy?  No problem you can just revert back to the last version.

You can find our blog post about it here:

blog.lavablast.com/.../I2c-for-one2c-welcome-our-new-revision-control-overlords!.aspx

Thanks for the tip. This is really cool and very helpful in our case.

Paul, if you build the web.config handling into your build process (if you use ASP.NET, using Web Deployment projects), then you can use svn to deploy web.config and all.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

We use subversion to update our integration / testing server and then run vice-versa between that and the production server, which very quickly moves only the files that have changed.

I use SVN to manage the the production environment for the company I work for.  And although I don't use it currently I built a web interface for a past client that would allow them to update their production environment from an SVN repository.  I used some classes from AnkhSVN for that solution.

Why would you want to deploy with all those SVN folders?  Also, if it's a web application project why would you want to deploy with all the .file_extension.cs and .designer.cs files?

I can see how it could work but I prefer cleaner deployments.

Our set-up:

- team checks code itno SVN

- build server with CCNet automatically checks for code updates every 10 minutes or so, rebuilds if code updates are found

- new builds are automatically deployed to DEV server

- on request, deploy of a specific build to INT(egration) server can be done

- ditto for PROD

Actually, code that's gonna be deployed to INT is branched first. So it's always a specific branch that is deployed to INT (or PROD), whereas the trunk is used for ongoing development (though we also use branches to develop things that can't be in the trunk yet).

We've actually written an interface where we can select which branch of which project needs to be deployed to which server in which environment.

Pingback from  Dew Drop - May 6, 2008 | Alvin Ashcraft's Morning Dew

Our customer facing site is 4 gigs with all the artifact files.  We have 2 designs and 2 developers that belong to different departments and it was a nightmare to keep track of changes.

I (one of the developers) wrote a few tiny utils to parse svn logs and svn info to find files that were added, changed, deleted and using that info built nant scripts for each process.  I zip up any files that have been added or changed from our working copy and run the nant script for those that were deleted.  

I created a web interface for the designers so that after they commit a change they can hit the web interface, choose the revision number and start the deployment.  The web interface also has an iframe that points to a local CC.NET, staging CC.NET and prod CC.NET.  After they choose the revision they do a force build local which moves everything to staging.  do a force built on staging to run a backup and deploy.  after they test then do a force build on prod.

Using Subversion as a Deployment Tool