I'm looking at Django[http://www.djangoproject.com/], and the entire system appears to favor deployment via SVN. Documentation warns you when you're not reading from SVN trunk; and people in #django claim it's easier to follow the SVN mechanism.
My gut preference is to just have Django available in apt-get and receive updates via those Ubuntu LTS. I get some amount of peer review, automated deployment, and versioned dependencies. Are these people crazy, or am I missing something?
Running it from svn is perfectly sensible. Now, running it from svn trunk is not. At all.
How do you know what you are running if you are on trunk? No, run the development and test machines on trunk. When you are ready to release, do so, by tagging everything. Update the staging server to these new tags and test. If all is well, update the production server too.
This goes no matter if it's your svn server or somebody elses.
I have to say that running a web-app from your OWN SVN repository is pretty sensible (though you need to be careful about what you commit!), but running it from someone else's SVN repository is probably asking for trouble. What you might want to do is set up a local repository that's a sort of 'gated mirror' of the official one. You can pull official sources in on a branch, test them, then move them to the trunk (or whatever) when you are confident in them.
My only real objection here is that you (as the guy who has to keep the web-app running) don't have any control over the Django SVN repository. At least with Ubuntu packages, you have some assurance that someone besides the developer has looked at it and found it to be at least semi-stable. And it's easy to update a test system first.
Running from SVN (or another source control server) makes sense if you are using released branches. It makes sure that critical security updates, which happen to scripted web applications far more often than binary applications, are applied frequently. Since most customers use SVN to pull down updates to web apps, you will often find that the apt-get repositories (or other distribution repositories) update less frequently and you will miss out on new features and security patches. Additionally, as web applications tend to 'mutate' rapidly and introduce backwards-compatibility breaking updates frequently, when the package does finally update you'll have a greater chance of having your specific app break.
As an example, Apache 2.2.11 is the current version, released last December. IIRC, my only Ubuntu server, which is hosting one specific application, is running 2.2.8. I can't seem to find a handy table for release dates in the httpd-2.2 branch, but the archive site says that changes-2.2.8 was published in early 2008. In that same period, the Zend Framework trunk grew from 50k lines of code past 20M lines of code.
If I were you, I would use svn:externals with the base package, and then add your own modifications to the subversion repository and stay up to date on security warnings that deal with whatever your web app's dependencies are. If you're into continuous integration, you can run the test suites in your environment and with your modifications so that you're aware when various trunks and branches are stable against your specific uses, and can update at will when security vulnerabilities are found.
I've run into a similar situation with TurboGears, another Python-based web framework. I had started out with the packaged versions from Debian, installed as you described via apt-get. However, I pretty quickly discovered that the web development world moves much quicker than the Debian packaging and release process. Ubuntu is a bit better in this regard, but only if you upgrade to each new release and don't stick to LTS releases.
My solution has been to make use of virtualenv to create a virtual Python installation for each main application, and then use setuptools' easy_install to install the latest released version of the necessary Python libraries from the pypi repositories. This isn't ideal, as it would be much nicer to use a single software management system, but it has allowed us to track recent release versions of important packages without having to pollute the main system versions installed by Debian/Ubuntu.
This approach seems safer than using a direct SVN checkout, which could become broken at any time with a bad commit. It means you're a bit farther behind from the bleeding edge, but that's probably what you want for a production server.
We run an in-house web app (a CMS) off an SVN working copy. It makes it much easier to update it from the repository, and if we make a change we want to commit back we can easily do so. No problems so far.
I prefer local branches, since SVN doesn't have the possibility of local commits I usually use git-svn.
Let's me easily do sanity checks with the upstream SVN trunk (or the tag/branch in question) and then commit to my (site-)local repo from which the real deployment starts.
Note: git was not easy for me to get used to (about 2 weeks) and I still run into some minor troubles (don't ask me why but reverting still is something where I shoot myself in the foot) but the superior features are worth it everytime.
On another note, you might get along with svn externals, I'm not sure wether it's possible to use certain revisions with svn externals but that could work for a defined update mechanism.
