在我正在开展的项目中，我们在开发团队之间进行了持续的讨论 - 生产环境是作为SVN存储库的结账部署还是作为导出进行部署？
开发环境显然是一个结账，因为它不断更新。 对于制作，我个人会检查主干，因为它使未来的更新更容易（只需运行svn update）。然而，一些开发人员反对它，因为svn使用svn进程的组/所有者和权限创建文件（这是在Linux操作系统上，所以那些事情很重要），并且在生产中也有.svn目录似乎他们有点脏。
此外，如果是结帐 - 如何在不包含开发代码的情况下将单个功能推送到生产中？你是否为每个功能使用标签或分支？任何替代方案？
编辑：我可能不太清楚 - 其中一个要求是能够始终能够将修复程序推送到生产环境中。我们希望避免完整构建（比简单更新需要更长的时间），仅用于推送关键修复。
答案 0 :(得分：13)
The Subversion FAQ似乎主张将部署作为结帐，并使用提交后挂钩脚本进行自动更新。它们通过在httpd.conf中添加以下内容来阻止Apache导出.svn文件夹（可能是个好主意）：
# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all
</DirectoryMatch>
我自己也很新，但也许你可以在创建一个新标签时触发一个钩子脚本。这样，当您准备好更新实时网站时，您只需将最后一次更改提交到主干，创建新标记，脚本将使用svn update更新您的实时网站。
答案 1 :(得分：10)
我一直在努力解决这个问题，我想我终于决定结帐了。是的，那里有额外的垃圾，但是......
不是说这对每个人都有效，但这两件事影响了我的决定。祝你好运。
答案 2 :(得分：9)
恕我直言，您应该创建一个分支/标记，其中包含您用于生产的dev env的（所需）子集。有人应该手动维护或使用脚本自动维护。然后，您应该导出（而不是结帐）。增量更新不是问题，除非您要更改生产环境中的文件，并且不希望覆盖这些文件。
只需我0.02美元
答案 3 :(得分：8)
毫无疑问 - 出口。
您不会进行更新，因此没有理由进行结帐。你只需要部署垃圾。
我想说任何环境都应该只是出口;您只在开发时使用本地结帐。当然我们也在使用构建脚本，因此更新部署就像运行脚本一样简单。
就开发代码而言，为正在完成的任何工作创建分支。只有在准备好部署到开发环境时才提交到主干。
答案 4 :(得分：2)
我会研究一些像Capistrano这样的部署软件（这是一个红宝石程序）
如果您要使用滚动自己的解决方案或手动，我个人会使用导出标签的trunk副本而不是导出trunk。
答案 5 :(得分：1)
我将其部署为副本。当然不是手动的。
我使用'make'和'checkinstall'。我创建了一个小的Makefile，它使用系统命令'install'将所有需要的文件复制到Web服务器上的相应目录中，并且我有预安装和postinstall shell脚本将在服务器上运行。
当部署时间到来时，我只运行'checkinstall'创建一个包（RPM，DEB或TGZ，具体取决于我所针对的Linux发行版）。我使用Linux发行包管理器（rpm，dpkg，pkgtool）提供的常规工具安装它。当然，如果你想跟踪依赖关系，你可以使用yum，apt-get等。
如果您想要分发新版本的网络应用，这将非常容易。到多个目标服务器。诸如卸载，恢复到旧版本等等之类的东西非常简单，因为您为部署的每个版本都准备好使用软件包。
如果您使用某些需要编译的内容，这可能不适合您的“经常推送”策略。但是，对于脚本编写的东西（比如我做的PHP），在我的机器上创建一个包（大约300多个PHP文件）大约需要20秒。并且可以在任何目标系统上安装它。
要将代码'for release'与'in-development'代码分开，我使用分支。使用Git，它非常简单，因为分支便宜且快速。
答案 6 :(得分：1)
我个人总是对此问题的解决方案存在疑问， 我更喜欢在我的生产环境中没有“.svn”目录，它非常脏 但与此同时，大型Web应用程序的导出非常繁琐（特别是如果使用Extjs，FCKeditor等部分第三方“组件”。）。
我认为目前没有“杀手级解决方案”。
答案 7 :(得分：1)
让我看看..... ln -s？什么可以用于？
/var/www/www.my-prod-site.com/public/
/var/www/www.my-prod-site.com/builds/Rev 1/
/var/www/www.my-prod-site.com/builds/Rev 2/
/var/www/www.my-prod-site.com/builds/Rev 3/
/var/www/www.my-prod-site.com/builds/Rev 99/
将svn导出到您的构建directorys ......从/ public复制任何配置文件，这是您以前的发布版本的符号链接，然后只需将符号链接从public转移到指向新构建目录。离线时间比我在这里发布的任何东西都要少，而且除非你每次通过改变表格来 ck p你的数据库，否则它也会更快地回归。
答案 8 :(得分：1)
以下是一些意见 -
生产中的.svn文件是脏的吗？ 如果.svn目录完整而且没有损坏，它们远非脏，它们实际上是救命稻草。为了安全起见，您可以告诉apache以防止浏览它们。
结帐或出口？我的做法...... 我肯定使用标签和分支 - 将生产服务器连接到主干并且祈祷没有人在有人将错误的代码提交到主干中以查看它在DEV上的作用之后运行svn是危险的。 我有一个可重复使用的标签（比如_production和_staging），在我的设置开始时，我会将每个标签检出到匹配的服务器。然后我锁定所有访问权限以修改live和staging服务器的内容。此后，DEV服务器连接到主干头。当代码足够稳定以进行QA / staging时，我们创建一个标记并将其重命名为_staging，以允许登台服务器在看到对该标记的更改时同步到它（脚本运行'svn up'）。一旦我们对_staging感到满意，我们将其重命名为_production，并使代码部署到实时服务器。 或者，您可以创建具有不同名称的标记/分支，并使用“svn switch URL”将服务器指向新标记/分支（固定点）。以上所有内容使得部署非常容易，无需停机，如果需要回滚，您可以快速重命名已存档的旧标签或使用'svn switch OLD_URL'立即撤消新的更改，而无需担心每个小文件和行更改。< / p>
权限＆amp;所有权 如果您了解并了解文件的权限，则可以在每次部署后运行脚本，将CHOWN和CHMOD设置为您希望的结果。
恐惧与知识 我听说很多人害怕生产服务器上存在SVN。相反的是实际上非常可怕。如何确保您的产品团队和客户不会崩溃成大堆或错误消息而无法执行干运行或'svn status -u'以确保部署只修改那些需要的文件更改？检查状态让我甚至知道是否有人强迫他们这样做并直接在服务器上进行“快速更改” - 你知道人们倾向于绕过那些看起来很快的事情的规则。
影像在实时服务器上有错误吗？使用.svn，您可以确定与其同步的确切版本（svn info），然后检查该URL是否为真（sv status -u）。然后，您可以通过将相同的标记/版本签出到沙盒服务器来构建该设置的诚实副本，以便您可以安全地进行故障排除。
答案 9 :(得分：-3)