从svn中的repos部署的方法

Question

我们是5个在svn环境中工作的开发人员。 每个程序员都可以处理小错误并随时提交。 工作完成后，我想给他们部署到生产的方式，而不考虑其他程序员及其部署。 例如： 当我提交时，其他用户也承诺，但他没有完成提交。 他的修订1,3 我的修订版2,4

如果我将部署HEAD（4），生病也会部署他的工作。 我将部署2和4，我也将包括他的文件。

我怎样才能让每个程序员都免费部署他的文件？

由于

Answer 1

显而易见的解决方案是每个开发人员使用一个分支，并在工作完成后才合并到主干。但这会增加相当大的开销。此外，随着更大的代码块将被集成，集成成本将会上升。

理想情况下，开发人员只会提交完成的工作。但是，提交和集成通常对于保持集成工作的重要性。

也许您应该考虑使用分布式版本控制系统。开发人员可以随意提交和恢复他们的本地存储库，并在错误修复后推送和拉动。

在没有标记的情况下部署到生产服务器会让我感到紧张。

Answer 2

这实际上取决于您的部署方法。如果你在生产中保留一个版本化的代码树，也就是说，你在生产机器上做了svn checkout，那么最简单的方法就是让程序员在生产时只使用svn update --revision REV，其中REV是程序员希望更新的修订版。

但是，这种方法容易出现人为错误。

如果每个程序员都需要一直根据自己的代码上传不同版本的程序，而不上传其他程序员的代码，那么我会为每个程序员设置自己的分支。程序员可以随时签入他们自己的分支，当它准备好投入生产时，他们可以将他们的分支合并回主干（或另一个发布分支），并且可以通过{{1}将主干复制到生产中。 }或svn export。这种过程用于保证您始终拥有一个工作版本分支，如果您的程序员习惯检查未完成的代码（即每天结束时），则此过程特别有用。 / p>

Answer 3

我认为您正在尝试做的是将部分更改与部署隔离开来，因此可以部署错误修正，但尚未部署新功能，因为他们必须等待新版本。

您可以通过创建发布分支并从中进行部署来实现此目的。在这种情况下，所有用户都将其更改提交到trunk，并将一些更改合并到release分支。

我不认为仅部署1个人的更改是有用的，因为版本控制的整个想法是在项目上一起工作，并且一起完成更改/错误修正。

看一下svnbook中的Branching & Merging。

Answer 4

您可能希望了解使用主干和分支机构。特别是，听起来 feature branching 可能适合您。