我工作的一组开发人员大约半年前从VSS切换到SVN。从CheckOut-CheckIn到Update-Commit的过渡对很多用户来说都很难。现在他们不再被迫在完成文件时检查他们的文件(或者更确切地说,现在没有其他人可以看到他们已经检出文件并告诉他们重新检查以释放锁定文件),不止一次,用户忘记了提交更改,直到完成后不久。
虽然大多数用户都很擅长提交更改,但问题非常严重,可能会决定强制用户get locks on all files in SVN before editing。我宁愿不看到这种情况发生,但我对如何以另一种方式改善情况感到茫然。所以任何人都可以建议如何做以下任何一种方式:
开箱即用的解决方案欢迎(即:如果用户在给定的时间间隔内没有提交,则提醒用户提交的桌面程序会自动获取用户提交率的统计信息,并在频率低于某个特定时间时发送警告电子邮件门槛等。)
答案 0 :(得分:14)
......用户忘记了他们的更改,直到他们完成很久。
我认为这就是问题所在。如果没有签入,功能/错误修复如何“完成”?您是否有问题跟踪系统来记录未解决的问题?您是否有一个持续集成系统,一旦签入就运行单元测试?
如果开发人员只是在没有责任的情况下做自己的事情,那么你遇到让每个人都合作的问题并不奇怪。您需要某种疏忽(项目经理?团队领导?),他负责确保各个开发人员与开发团队的其他成员合作。
答案 1 :(得分:6)
您是否使用任何类型的错误/功能跟踪软件?
您可以要求他们在完成工作时勾选修订号。
答案 2 :(得分:6)
如果您之前使用过VSS,则可能在Visual Studio中工作。 AnkhSVN有一个挂起的更改窗口,如TFS和VSS中的窗口。此工具窗口自动显示解决方案中本地修改的文件。
使用此暂挂更改窗口进行更改可以轻松处理小/逻辑更改并提前提交这些更改,而不是稍后提交。
[查看较旧的AnkhSVN版本的屏幕截图]
答案 3 :(得分:5)
我认为你遇到的问题实际上是缺少一个带有跟踪错误/功能/变化的连续构建系统组合。通过错误跟踪系统和连续构建,开发人员只有在他的更改进入自动构建并且构建了包含更改的发行版之后才能声明“完成”,通过构建验证测试并将其放在发布放置位置。由于改变“使”成为构建的唯一方法是签入(可能反向将功能分支集成到主分支/主干),开发人员必须签入,否则他们永远不会完成任何事情
答案 4 :(得分:4)
获取自动构建计算机(或至少一个专门负责构建的人),并仅从该计算机进行部署。然后,在您提交之前,您的代码不会被部署,这有助于确保存储库中没有任何内容。
此外,至少有一些团队成员提前做出承诺,并且通常也会鼓励其他成员继续跟进,因为缓慢的提交者必须处理更多的本地合并冲突。
答案 5 :(得分:2)
在一个小型开发小组中,我看到每天发送一封电子邮件到该组的邮件列表,其中显示了前一天的签到摘要以及一个非正式的“赛马”,其中显示了签到,总线等数量过去30天是有帮助的。显然你不能使用多种签名作为任何一种性能指标,但它仍然很有趣并且保持对每个人心灵的源代码控制。 “嘿,乔本月刚刚把钥匙递给我,哦,等等,我昨天从未检查过该代码。”
这也有其他优点,因为人们在早上进来并通过他们的咖啡阅读它或者其他人在开发人员心中所做的事情。当我们进入“代码冻结”并接近发布时,我们实际上只是通过签入摘要更改电子邮件,以包含实际的“差异”,以便每行代码都能立即获得许多目标。
答案 6 :(得分:1)
通常,鼓励开发人员经常提交的事情是自我保护。当由于合并冲突导致更新变得困难并且他们发现通过推动更改来缓解问题时,他们会更频繁地提交。
但是,听起来确实存在一些根本性的错误。您的开发人员如何在不通过VCS的情况下对已发布的产品进行更改?你应该关上那扇后门。答案 7 :(得分:1)
自动构建和部署,并使其成为流程的一部分,在测试服务器上测试之前,没有任何“完成”
答案 8 :(得分:0)
阅读提交日志并询问人们他们的状态以及他们何时会检查他们的更改。承诺整件比承诺好像是一种“拯救”的方式。
开发人员如何完成某些操作并忘记检查?交付流程是否使用户从开发人员自己的机器运行构建?
答案 9 :(得分:0)
一个不错的错误/功能跟踪器将允许您在提交更改时添加错误号。例如,如果我正在运行Redmine,我可以在我的subversion提交消息中的某处提交“Fixes#323”,它将自动关闭bug /任务323.它的设置非常简单;你只需告诉Redmine存储库的位置,无论如何都要求。
通过这种方式,您可以查看针对每个错误提交的更改,并且将打开没有提交的错误(除非手动关闭)。您可以将bug分配给里程碑,并在发布里程碑之前,查看针对该错误的提交。
Trac也像其他许多人一样这样做。