QuestionIs there a legitimate reason NOT to use SVN for production deploys, or is this merely a case of personal preference and there is no real case against SVN?BackgroundMy workplace has a culture of tagging release in SVN and then deploying those releases directly to the various web servers using svn co or svn switch including directly to production.I personally have a problem with this as I believe that without using a build and deploy script or some form or automated deploy you lose integration environment settings as they're undocumented.  However more than that I have a gut feeling that there may be a hidden danger to doing that which has been overlooked, something which has yet to rear its ugly head.I've brought up my concerns with the operations staff who are responsible for deploying code to our various environments (staging, pre-prod, production) etc.  Their arguments were pretty much that it's worked pretty well so far, no reason to change.Edit:What I mean about build and deploy:For example, if a developer requires a web.config setting added for a particular environment. Web.config is generally not kept in svn and so these files are updated manually without any form of automated build script. So if they're lost or OPS forget to add a field to the web.config for a release then you have issues. A build script that say uses XMLPoke to automatically generate a web.config appropriate for a particular environment is ideal in that you have a versionable script which documents all changes necessary for each of your environments.Current Build and Deploy MethodFor the project in question a developer builds a release manually, other projects have the build step automated either with NANT, or MSBuild which is OK.Database migrations for most projects are via DB scripts, or migration scripts (Migrator.NET), or CMS Packages.CI is usually done by Team City on a per checkin basis, we have a code review process that all tickets are done in branches and then peer reviewed for validation and correctness/quality prior to checking into trunk (works well).However actual code deploy is pretty much always via SVN, either via a checkout of a tagged release or more generally an SVN Switch.  This is something that sticks odd with me that we're using our repository as part of the deploy process.Configuration doesn't generally change very often, the only things that will be in config files are environment specific information.  Everything else is in the db.Don't get me wrong this works, it works well.  However I want to try and push for an automated build and deploy.  I've used this with Rails and Capistrano, and for personal projects using Cygwin, Nant and SSH.  More importantly I would need very specific valid arguments to get my colleagues to change to using an Automated build and deploy.Or are there NO real valid arguments against using SVN specifically to deploy to production?
Is it acceptable to deploy web app to production directly from SVN
web development;svn;deployment
From my experience, there are both advantages and disadvantages:Pros:Sometimes you make urgent hot fixes on the production server, then you can check them back in directly from there. (Although theoretically, for security reasons it's always a good idea to use read-only access to the repo from the production server.)Simplicity: you deliver quickly, although as others mentioned here, switching to an update-script scheme can be as easy.Cons:Your system can become unstable during your svn up and DB updates. For a high-traffic site this means some users will hit error messages, broken pages or empty pages at best. Well, that's what we very often see on various social services. A good service, however, does it atomically in a sense that it puts the system into maintenance mode for the duration of an update. (You broke reddit!)Conflicts: resolving sudden conflicts on the productions server is a terrible idea: again, the service becomes unstable while you're fixing it.Unrelated files on the production server which may or may not belong to you, although of course you can avoid it by checking out the right subtree in the repo.Security: someone who gained access to your production server, legitimately or not, also gains access to your repos, possibly other products as well, and possibly also with write access! Overall opening up your internal SVN server to the outside world is a bad idea. Your source repositories should be behind a company firewall, period.There are going to be update scripts anyway, e.g. for updating the DB structure, managing cronjobs, etc, so why not having a script that does it all? - i.e. pulls the latest pre-packaged release, switches to maintenance mode, updates sources, runs release-specific scripts etc.Edit: for those still on the SVN scheme, don't forget this in your apache config:<DirectoryMatch .svn>    Order deny,allow    Deny from all</DirectoryMatch>