我正在查看Django，整个系统似乎都倾向于通过SVN进行部署。 当您不从SVN中继读取文档时，文档会提示您; #django中的人声称跟随SVN机制更容易。
我的直觉是只要让Django在apt-get可用，并通过这些Ubuntu LTS接收更新。 我得到了一些同行评议，自动部署和版本依赖。 这些人是疯了吗，还是我错过了什么？
从svn运行它是非常明智的。 现在，从svn trunk运行它不是。 完全一样。
你如何知道你在干什么？ 不，在干线上运行开发和testing机器。 当您准备好发布时，通过标记所有内容来实现。 将登台服务器更新到这些新标签并进行testing。 如果一切正常，也更新生产服务器。
不pipe这是你的svn服务器还是其他人。
我不得不说，从你的SVN仓库运行一个Web应用程序是非常明智的（尽pipe你需要小心你的提交！），但是从别人的SVN仓库运行它可能会遇到麻烦。 你可能想要做的是build立一个本地存储库，这是一个官方的“门控镜像”。 你可以把一个分支上的官方消息来源，testing它们，然后当你对它们有信心的时候，把它们移到树干（或其他）。
我唯一真正的反对意见是，你（作为那个必须保持web-app运行的人）不能控制Django的SVN仓库。 至less在Ubuntu软件包中，除了开发人员之外，你还有一些保证看到它，并发现它至less是半稳定的。 首先更新testing系统非常简单。
从SVN（或另一个源代码pipe理服务器）运行是有意义的，如果你正在使用发布的分支机构。 它可以确保经常应用比二进制应用程序更经常发生脚本化Web应用程序的关键安全更新。 由于大多数客户使用SVN将更新下载到Web应用程序，因此您经常会发现apt-get存储库（或其他分发存储库）更新频率较低，您将错过新function和安全补丁。 此外，由于Web应用程序倾向于快速“变异”，并频繁地引入向后兼容性中断更新，当程序包最终更新时，您将有更大的机会让您的特定应用程序中断。
例如，Apache 2.2.11是去年12月发布的最新版本。 IIRC，我唯一的Ubuntu服务器，托pipe一个特定的应用程序，运行2.2.8。 我似乎无法在httpd-2.2分支中find发布date的便捷表格，但归档网站上说，2008年初发布了2.2.8版本的更改。在同一时期，Zend Framework主干从5万行的代码超过20M行的代码。
如果我是你，我会使用svn：externals与基础包，然后将自己的修改添加到Subversion版本库，并保持最新的安全警告，处理任何您的Web应用程序的依赖项。 如果您正在持续集成，则可以在您的环境中运行testing套件并进行修改，以便您了解各种干线和分支在针对您的特定用途时是否稳定，并在发现安全漏洞时可以随意更新。
TurboGears是另一种基于Python的Web框架，我遇到了类似的情况。 我已经开始使用Debian的打包版本，正如你通过apt-get所描述的那样安装。 不过，我很快发现，networking开发世界比Debian的打包和发布过程要快得多。 Ubuntu在这方面稍微好一些，但是只有升级到每个新版本，不要拘泥于LTS版本。
我的解决scheme是使用virtualenv为每个主应用程序创build一个虚拟Python安装，然后使用setuptools的easy_install从pypi存储库安装必要的Python库的最新发布版本。 这并不理想，因为使用单个软件pipe理系统会更好，但是它使我们能够跟踪重要软件包的最新版本，而不会污染Debian / Ubuntu安装的主要系统版本。
这种方法似乎比使用一个直接的SVN签出更安全，这可能会在任何时候被一个不好的提交破坏。 这意味着你离创新点还有一段距离，但这可能是你想要的一个生产服务器。
我们运行一个内部的networking应用程序（CMS）closuresSVN的工作副本。 它使得从存储库更新它变得更容易，如果我们做出改变，我们想要提交回来，我们可以轻松地做到这一点。 到目前为止没有问题。
我更喜欢本地分支机构，因为SVN不具有本地提交的可能性，我通常使用git-svn。
让我们轻松地对上游SVN中继（或标签/分支）进行完整性检查，然后提交到我的（站点）本地回购，真正的部署开始。
注意：git对我来说不是很容易习惯（大概2周），我仍然遇到一些小问题（不要问我为什么，但是回复仍然是我在脚下拍摄自己的东西），但优越的特点是每次都值得。
在另一个说明中，你可能会和svn externals相处，我不确定是否可以对svn externals使用某些修订版本，但是可以用于定义的更新机制。