几个开发人员和一个Subversion的工作文件夹

Question

我们正在使用巨大的脚本语言网站，这很难在每个开发人员工作站上部署。有几个开发人员需要在服务器上的一个Subversion的工作文件夹中工作时，是否有任何机构遇到这种情况？

Answer 1

这听起来错了。你将如何管理单独的登录，并发更改？为了您自己的理智使用多个WC！

看来你正在从源代码控制中拿走60％的好东西并将其扔掉。

Answer 2

“......几个开发人员在一个颠覆的工作文件夹的工作......”

不，他们没有来。这只是滥用VCS。

如果你这样做，它会受到伤害。如果你不想让它受伤，就不要这样做。就这么简单。

（现在，如果你告诉我们为什么你认为他们有必要，我们也许能够在一个解决方案来点你。）

Answer 3

设置自动集成工具，将更新测试服务器每次提交的最新版本。这样每个开发人员都可以在本地编辑并提交。请参阅Cruise Control了解此类工具的示例。

Answer 4

正确的做法是每个人都有自己的工作副本。如果您希望在某人提交文件时自动更新网站，那么在Subversion服务器上，设置一个post-commit挂钩脚本，将ftp或scp（或其他任何协议）文件转发到Web服务器。

我已经做了几次，而且效果很好。 Subversion被设计来做这样的事情。

Answer 5

您可以设置一个与您的生产服务器相同的开发服务器，让每个用户使用SVN客户端将文件检出到开发服务器上自己的目录中。远程编辑和测试文件，然后提交回存储库，并在准备发布发布时导出（或签出）到生产环境。

Answer 6

听起来您的组织中存在变更控制担忧以及缺乏持续集成的做法，这些做法使得扩展开发和灾难恢复变得更加困难。

您需要说服您的利益相关者，您的开发人员应该从分支开始工作，并且您的生产环境应该有可部署的脚本化方式。如果您需要专有安装程序（ISS等），请使用部署脚本以及默认安装以及生产调优系统。

您的开发人员对分支进行了更改，他们可以使用持续集成方法将该分支部署到测试/临时服务器。然后，当您的利益相关方接受登台服务器的操作时，将更改部署到生产服务器。如果该部署失败，则任何灾难恢复也会失败。如果您的灾难恢复失败，那么您的源代码管理技术对您的组织而言没有价值。灾难恢复需要成为您的验收测试的一部分。

即使三位开发人员在一台也作为临时服务器的工作站上轮流工作，它仍能正常工作。每个人都有自己的用户帐户和单独的工作目录，登台服务器只是一个集中式目录。

Answer 7

如果你这样做，你将会处于一个痛苦的世界。你几乎失去了拥有VCS的所有优势。从本质上讲，你已经将SVN归入备份工具的角色。这不是VCS应该做的。另外，只要你有多个客户同时在同一个WC上工作，你就会遇到麻烦。至少，会有锁争用，需要你运行“svn cleanup”。如果您通过网络共享访问WC，结果可能会更糟糕，因为SVN的锁定机制不能通过网络共享工作。你可能会以非显而易见的方式摧毁WC，导致后续提交中包含错误更改。 SVN文档警告不要通过网络共享使用多个客户端。

保存版本控制问题，开发人员通信问题和集成问题，并为每个开发人员提供自己的工作场所。在主服务器上有不同的目录，或者（甚至更好）让它们设置为在本地运行该站点。你永远不会发现你的共享WC的集成/部署问题，你仍然会错过一些共享服务器。

Answer 8

正如大家所指出的那样，您放弃了使用您的建议设置进行版本控制的好处，让开发人员不断努力工作（而不是固定成本的一次性成本），并冒着严重的风险损伤。不要这样做。

如果很难在工作站上部署（也许是因为有很多的敏感组态软件），然后我看到了两个很好的选择：

1. 为每个开发自己的私人空间在服务器上，只有开发团队可以访问。这意味着服务器配置只需要完成一次，但每个开发人员都可以私下工作而不会破坏事情。
2. 拍摄您的生产服务器的映像，并对其进行足够的修改，使其可以在每个开发人员的工作站上的VM中运行。将其用于本地部署，然后从存储库部署到生产服务器。

Answer 9

谢谢你的回答。我们的网站正在使用一些我们无法在开发人员工作站上部署的特定软件。是的，所有开发人员都有自己的登录到SVN，但目前他们必须在服务器上的一个工作文件夹上工作。主要问题：当几个开发人员执行几个不同的任务时，如何保持SVN和工作文件夹同步。