我们正在使用庞大的脚本语言网站,这很难在每个开发人员工作站上部署。当几个开发人员必须在服务器上的一个subversion的工作文件夹中工作时,是否有任何机构遇到这种情况?
答案 0 :(得分:7)
这听起来不错。您将如何管理单独的登录,并发更改?使用多个WCs为您的理智!
看起来你正在把60%的好东西从源代码控制中拿出来扔掉。
答案 1 :(得分:5)
“......一些开发人员必须在一个subversion的工作文件夹中工作......”
不,他们没必要。那只是滥用VCS。
如果你这样做,那就会受伤。如果你不想让它受伤,就不要这样做。就这么简单。
(现在,如果您告诉我们为什么您认为他们必须这样做,我们可能会指出您的解决方案。)
答案 2 :(得分:4)
这样做的正确方法是让每个人都拥有自己的工作副本。如果您希望在有人提交文件时自动更新网站,那么在Subversion服务器上,设置一个post-commit钩子脚本,该脚本将ftp或scp(或任何协议)文件传输到Web服务器。
我已经做了几次,而且效果很好。 Subversion旨在做这样的事情。
答案 3 :(得分:2)
正如大家所指出的那样,你放弃了你提出的设置版本控制的好处,让你的开发人员不断努力(而不是一次性解决这个问题的成本),并冒着严重的损失。不要这样做。
如果在工作站上部署很困难(也许是因为有很多软件具有敏感配置),那么我会看到两个不错的选择:
答案 4 :(得分:1)
设置一个自动集成工具,在每次提交时使用最新版本更新测试服务器。这样每个开发人员都可以在本地编辑并提交。有关此类工具的示例,请参阅Cruise Control。
答案 5 :(得分:1)
您可以设置与生产服务器相同的开发服务器,并让每个用户使用SVN客户端将文件检出到开发服务器上的自己的目录中。远程编辑和测试文件,然后提交回存储库,并在准备发布版本时将其导出(或签出)到生产中。
答案 6 :(得分:1)
听起来您的组织中存在变更控制担忧以及缺乏持续集成实践,这使得扩展开发和灾难恢复变得更加困难。
您需要说服您的利益相关者,您的开发人员应该在分支机构工作,并且您的生产环境应该具有可编写脚本的部署方式。如果您需要专有安装程序(ISS等),那么使部署脚本可以使用默认安装以及生产调优系统。
您的开发人员对分支进行更改,他们可以使用持续集成方法将该分支部署到测试/临时服务器。然后,当您的利益相关者接受登台服务器的操作时,您将更改部署到生产服务器。如果该部署失败,则任何灾难恢复也将失败。如果您的灾难恢复失败,那么您的源控制技术对您的组织没有任何价值。灾难恢复需要成为验收测试的一部分。
即使三个开发人员轮流使用一个也充当登台服务器的工作站,这也可行。每个都有自己的用户帐户和单独的工作目录,而登台服务器只是一个集中的目录。
答案 7 :(得分:1)
如果你这样做,你将陷入痛苦的世界。你几乎失去了拥有VCS的所有优势。从本质上讲,您已将SVN降级为备份工具的角色。这不是VCS应该做的事情。此外,只要您有多个客户同时在同一个WC上工作,您就会遇到麻烦。至少,会有锁争用,需要你运行“svn cleanup”。如果您通过网络共享访问WC,结果可能会远远更糟,因为SVN的锁定机制不适用于网络共享。您可能以非显而易见的方式破坏WC,导致后续提交中包含错误的更改。 SVN文档警告不要通过网络共享使用多个客户端。
保存自己的版本控制问题,开发人员沟通问题和集成问题,并为每个开发人员提供自己的工作场所。要么在主服务器上有单独的目录,要么(甚至更好)将它们设置为在本地运行站点。您永远不会发现共享WC的集成/部署问题,并且您仍然会遗漏一些共享服务器。
答案 8 :(得分:0)
感谢您的回答。我们的网站使用的是一些我们无法在开发人员工作站上部署的特定软件。是的,所有开发人员都有自己的SVN登录,但目前他们必须在服务器上的一个工作文件夹上工作。主要问题:当多个开发人员实现多个不同的任务时,如何保持SVN和工作文件夹同步。