并不是说我在做这样的事情，而是我对这样的做法有多么糟糕很感兴趣。

解决方案

好吧，如果我们要签出的这段代码是基线(稳定)的，我认为这没什么大问题。

但是我们当然应该标记代码，以便以后知道放置在其中的内容。

可能比从测试服务器复制副本更安全，至少我们可以确保获得所有文件的正确版本，并且复制了所有文件。

如果我们谈论的是应用程序稳定性(或者代码)，则在部署期间始终存在风险。

但是除此之外，如果我们可以使用https而不是http，则存在安全风险。或者甚至使用SSH网关。

我不必评论所涉及的安全风险，但这可能会使我们陷入未经审查/未经充分测试的代码最终进入生产环境的情况。如果我们考虑使用svn作为将源分发到不同环境(开发，测试，生产等)的方法，建议我们采用以下方法：

将树的一部分保持稳定(很可能是树枝)，并使其成为该树枝的守门员。所有对"稳定"的承诺都必须经过它们，并且他们将负责确保未经验证就不会有任何结果。如果没有人想长期担任此职位，则可以每周或者每月轮换一次。

另外，如果我们只是想定期进行从颠覆到生产的临时转储，则可以使用" svn export"命令。

最后，如果我们只需要结帐以设置生产环境，那么我猜这是Web开发。如果是这种情况，请确保运行Web服务器的用户对存储Subversion元数据的'.svn'目录没有读访问权限。

只要服务器禁止从网络访问所有.svn目录，就没有限制。

我完全不认为这是安全隐患或者不良做法。这非常方便，我当然会在以后的项目中做一些事情。

例如，Capistrano(Rails自动部署解决方案)是围绕将代码从SVN签出到生产服务器而构建的。

我们可以做一些愚蠢的事情，这可能会使它成为一种不好的做法，但是它们都很容易缓解。例如：

• 在没有密码保护的情况下将svn存储库公开到网络上-不要这样做！
• 使用http而不是https公开svn存储库，这样一来，嗅探我们流量的人就可以获取密码-再次，不要这样做！只需通过https运行它即可。
• 使用具有svn读/写访问权限的帐户检出代码。我个人不会担心这最后一步，就好像它们危害了生产服务器一样，我们遇到了更大的问题，并且我们可以轻松地回滚他们可能尝试对svn所做的任何更改。如果我们极度偏执，可以为生产结帐创建一个只读的svn帐户。
• 检出主干到生产环境-仅当使用不稳定的主干运行时这才是问题，我们只需检出稳定的分支/标记以进行部署即可。

这是我的处理方式：

假设：

• 在单个根文件夹(projectroot)下的项目
• 所有文件均受版本控制

脚步

1确保存在"新"生产版本的标签

推理

2签出该标签或者将其导出到文件夹projectroot.new
3停止服务
4重命名projectroot.old << projectroot << projectroot.new
5重新启动服务
6如果我们需要后退，请反向执行步骤4

这是为了使实际的实现和后备步骤尽可能地基本。我们可以只使用svn开关，但是回退时出现的任何问题都可能导致系统损坏。

显然，这是最简单的情况，即不进行数据迁移，不进行未版本控制的配置文件等等。但我认为关键是要先构建复制树，然后再进行交换，以使我们获得清晰的切换和后备。

我不一定喜欢直接检出存储库以进行部署的想法。具体来说，我们是否需要将每个文件(如测试用例)部署到生产中？另外，我们将来会在某个时候生成任何代码吗？最好有一个构建系统来构建要部署的发行版。

但是，代替任何这些决定，请确保写下我们要同步的存储库的修订版。这样，同步是可复制的，并且如果生产中出现无法复制的错误，则可以将本地存储库同步回与生产一致的状态。

已经有一些不错的答案。但是，让我尝试以某种方式量化风险。

假设2个月前，木马的风险小到可以接受。随之而来的是卡明斯基(Kaminsky)的DNS攻击，这预示着特洛伊木马的风险从理论上的主动攻击上升到了"脚本小子"领域。这是因为大多数公共Subversion项目使用http或者https(如果使用https)，则它们不使用带有完整证书链的证书。然后，对手所需要做的就是对DNS进行毒害，并使用自己的木马克隆SVN服务器。

我发现使用SVN非常方便和可靠。我们的政策是保持中继稳定并在分支机构中进行非关键性的更改，然后在发布日期之前不久将这些分支合并到中继中。

对于较小/较不复杂的项目，它使发布像执行" svn up"一样简单。简化部署可以使非开发人员(sysadmin，电话支持等)在没有相关开发人员的情况下更快速地恢复有问题的更改。万一新版本出现问题，只需回滚到最后一个已知的稳定副本即可。

我唯一真正关心的是SVN元数据的可见性。确保已将Web服务器设置为拒绝对.svn目录(及其中包含的所有文件)的访问。我们可以使用svn导出，或者在发布过程中删除SVN元数据：find。名称.svn -print0 | xargs -0 rm -rf

我们不希望有人浏览www.example.com/.svn/entries，该网站会显示源代码存储库，用户名和文件。如果我们做了" passwords.conf"之类的愚蠢的事情(可能会被用户读取(取决于服务器配置))，那么这尤其糟糕，这并不是SVN的真正错。如其他答案中所述，我们也不想使用HTTP。

段落数量不匹配