当前的部署过程需要我们只移动当前SVN修订版和上次部署的SVN修订版之间的差异，这在我的项目中完美无缺。
其他项目抱怨这种方法，并希望部署所有内容，将每个文件从开发环境移动到其他环境，如测试、暂存或实时。
Java团队负责人和PHP团队负责人同意这一点。我是一名PHP开发人员，发现这种方式效率低下且无用。当我们决定通过复制所有内容进行部署时，我们不必使用这么多时间和带宽。
当我们使用 SVN 差异进行部署时，服务器管理员会保存一个压缩文件，其中包含与当前部署相关的所有已修改文件，因此当我们想要恢复时
更容易恢复。我只是想向公司的经理提出一些很好的理由，他在技术上意识到部署过程中的问题，只是为了让他明白，当部署后出现问题时，这是因为开发人员做得不对，而不是因为我们必须部署所有内容才能正常工作。我想说服他，使用 SVN 部署比完全不依赖 SVN 部署所有内容（原始复制/粘贴）要好得多。
（我不得不使用aswer，因为注释中没有足够的空间）
有趣的问题。
我猜Java开发人员（就像我一样）每次都只是用来部署整个应用程序（对于任何类型的不从源代码运行的语言来说，情况可能也是如此，就像PHP一样）。
在我工作的一家前公司，这是发布更新的方式，由于应用程序 WAR 超过 100 兆字节，整个过程总是需要几个小时，即使只有几个类发生了变化。
相反，在我现在工作的公司里，他们把一个有差异的系统放在一起，所以以一种类似于你描述的方式（当然，Java类文件必须完全替换）。
我认为这是一种更好的方法，更容易和轻量级。
由于 PHP 即使在运行时也依赖于源文件，因此我认为像您已经拥有的基于差异的方法更好。因此，您当前的方法为 +1。
因此，我认为更快的部署，更轻松的备份以及您在问题中提到的其他事情是保持当前方法的充分理由。
当然，重要的是可以随时从SVN生成和部署功能齐全的版本，并且可以毫无故障地替换服务器上相应的基于增量的版本（但我相信你已经有了）。
关于那些反对你的人：让他们证明（用现实世界的例子）你的方法在哪里有问题。
（也许这会更适合 programmers.stackexchange.com？
我们部署脚本的草图（我们使用Git，使用 Subversion 对算法没有任何影响，只是实际命令不同）。我们正在使用一个工作副本（带有 Git 的本地存储库）和另一个目录（名为 export ），其中准备了下一个版本的实时代码（如果您愿意，可以staging）：
- 更新代码的本地副本（
Gitgit pull，Subversionsvn update）; - 清理
export目录，然后将代码复制到其中; 我们使用rsync而不是cp，因为更容易为它提供它应该忽略的目录和文件列表（.git，.svna.s.o.）; - 将任何所需的配置设置应用于
export目录中的文件;例如，我们不会将敏感数据（用户、密码）保留到存储在存储库中的代码中，而是保留占位符值;此步骤将占位符值替换为实际的用户、密码、密钥 a.s.o。 - 做其他需要的修正; 例如，我们使用一些符号链接指向包含用户上传数据的目录; 在代码存储库中，我们有空目录; 在修复阶段，这些目录将从
export中删除，然后创建具有相同名称的符号链接; 符号链接指向 Web 根目录外部的永久目录， 数据的存储位置;此外，我们使用指向第三方库的符号链接 - 它们不存储在存储库中，并且它们的部署遵循不同的模式（它们通常被冻结为项目开始时的版本，以避免不兼容）; - 使用带有适当参数（
--archive和其他参数）的rsync使代码的实时版本与本地export目录中刚刚准备的版本相同。
您最有可能遇到的问题不是因为"每次都复制所有内容"，而是实际上由于将单个文件修复程序作为发布而不是将整个构建作为发布发布。最佳做法是捕获整个应用程序或应用程序组件的构建工件，一旦达到这一点，是否复制所有文件或仅复制已更改的文件就无关紧要了，因为该文件现在是部署软件的实现细节（无论是基本的文件副本， FTP，rsync或企业级工具，如我公司的产品BuildMaster）。