Arm*_*ndo 9 svn version-control perforce branch
我和我的团队目前使用Perforce进行版本控制.我们曾经把所有东西都提交到trunk,直到有一天我们需要在程序中添加几个项目,所以我们为我的老板创建了一个分支,为我创建了一个分支,另一个分支进行了测试.一切顺利,直到我们尝试将分支合并回主干.我们Visual Studio(VS)和它生成的解决方案文件由于某种原因,它不适用于Perforce.经过很多努力,我们将分支部分合并到主干中.我正在考虑转向颠覆.我在我的本地电脑上有Subversion,我对Visual Studio分支和维护没有任何问题.我建议老板搬到SVN.虽然我的老板对于移动50万行代码的想法持开放态度,但我需要建立一个强有力的案例.我是最年轻的毕业生程序员,所以说我的想法需要比其他人更多的牛肉=)
我决定在我们的一台服务器上安装SVN并将代码传递给它.我们不会很快摆脱Perforce,但我的目标是以非常缓慢的方式杀死它并且让我的队友变态SVN使用起来有多容易,我已经有一个人在我的船上.
由于我可以从头开始配置SVN,我想应用SVN的最佳实践.我读了红豆书,我打算按照他们的回购布局和备份提示,但我有更多与社交和分支问题有关的问题.以下是我对社会问题的疑问,
有没有办法以社交方式防止源冲突？如果是这样,沟通冲突变化的最佳方式是什么？
我也计划在该服务器上安装CMS.所以我的队友可以写作或传达他们有分支机构之类的东西,但我不知道是否还有其他工具来跟踪我们项目的历史性健康和缺陷.
即使我的公司采用扁平化管理方法,像我这样的新秀如何能够在不打破无形"高级"等级的情况下说服或强制与高级程序员进行社交沟通？
对于分支和标记,
我不希望其他团队分支在程序中添加"Hello,World!"代码.我想把分支视为一种与众不同的东西.任何人都可以给我一个关于何时添加创建分支的经验法则？什么时候合并？
在什么情况下分支分支是个好主意？
对于标记,我的理解是标记符号表示程序的静态点(即:v1.0,v2.5)是正确的吗？
如果我创建一个分支并开始编写我的更改,我的队友应该从我的分支开始同步吗？还是他们还应该在后备箱里发展？或者他们应该为自己创建另一个分支？
我为我的所有问题道歉,但是当涉及到版本控制时,我觉得我在BP清理过程中游泳了墨西哥湾.
Cor*_*rch 12
没有特别的顺序:
我实际上喜欢Perforce,我认为Perforce在跟踪合并方面比Subversion做得更好,但是Perforce存在一些问题,一个是与第三方工具的集成 - 尤其是VisualStudio.并且,(加上开发人员并不喜欢这么多的事实)使得很难在许多网站上推荐.
如果您打算开始转向Subversion,我会说您最好的策略是集成到您当前的工具中,以及Subversion与其他第三方工具有更多集成点的事实.
以下是我要点的一些观点:
您还可以指出Subversion和Perforce之间的相似之处,以及您喜欢Perforce的功能在Subversion中:
最佳实践是超越工具,尤其是版本控制系统.您将需要缺陷跟踪工具,持续构建系统和发布存储库.最佳实践是沟通和信任:
如果您可以展示您计划如何回答这些问题,那么您可以为您的计划建立一个强有力的案例.展示Subversion如何适应这些计划.展示如何使用VisualStudio更好地工作以及如何使开发人员的工作更好.
如果您正在构建.NET应用程序,我强烈建议您查看Nant.(我假设您通过打开VisualStudio并点击F5或者构建的任何内容来进行正式构建.如果您不这样做,那么您将领先于我见过的90%的VisualStudio站点).然后,您可以使用Hudson作为持续构建服务器.Hudson也可以充当发布存储库,因为它可以存储构建的工件.这意味着人们可以轻松访问官方版本.
最棒的是,通过Hudson插件,您可以标记哪些版本是正式版本,标记版本等.它集成了Jira,Track,Bugzilla,MantisBT和许多其他缺陷跟踪系统.它也适用于Redmine,包括缺陷跟踪系统,留言板,图表,维基等.这是您可以使用的另一个工具.
我们的想法是定义问题,定义解决方案,并展示Subversion等工具如何适应它们.
请记住,最佳实践不仅仅是一种可以反复重复实施的方法.这是了解您的项目的一种方式.它确保每个人都知道发生了什么.它确保每个人都完全信任这个过程.它确保您确切知道产品中发生了什么.
有各种各样的提示,人们一遍又一遍地重复关于最佳实践:可重复性,及早发现缺陷,自动化一切,敏捷开发,小口而不是进行大规模更改,不破坏构建等等.但是,这些只是手段到最后.请记住大局.
我还发现将这些工具出售给使用它们的人是绝对重要的,而且对于开发人员来说,你认为这样一个巨大的优势并不是那么好.开发人员希望能够获取他们需要的文件,进行修改并检查他们的更改.无论是Perforce还是Subversion还是CVS,他们都不会诅咒.他们不关心变更集或原子签入.他们不关心Interfile分支.他们只是想知道他们正在查看正确的文件,并且当他们进行更改时,它就会被传递.如果您要销售Subversion,您可以告诉开发人员如何改进他们的流程并让他们的生活更轻松.
保持简单.SCM的轻手最好.如果人们发现这个过程非常艰难,他们会尽力绕过它.
Couriosity只是闪耀出你的问题;) - 尽量不要迷失在一起做/想太多事情.
所以回答他们的问题..
1. 有没有办法以社交方式防止源冲突？如果是这样,沟通冲突变化的最佳方式是什么？
我所知道的主流源代码控制软件在将这些工作集成到另一个(合并)之前,会带来一个关于可能存在冲突的工作的良好实现通知.正如Corbin March提到的那样,除了DRY和关注点分离之外,我认为"每日更新","提前提交,经常提交"和"延迟提交"(见下文)都是实实在在的做法.
尽早承诺有其局限性.语法错误免费,并且根据您的bugtracker /任务组织系统,只应提交完整的工作工件.
恕我直言,当您遇到自己无法解决的源冲突时,要求帮助的社交技能确实不多.
2. 我打算到CMS安装到该服务器也是如此.所以我的队友可以写作或传达他们有分支机构之类的东西,但我不知道是否还有其他工具来跟踪我们项目的历史性健康和缺陷.
这听起来像一个非常"分布式"的方法.不是在位置而是在责任方面.您正在创建软件产品并偶尔做一些发布吗？因此,责任应该增加并集中进一步"下游".整个团队应该熟悉的唯一分支是用于修复东西的发布分支(没有功能)和主线(主干).所有其他事项,功能分支,集成分支,"备份"分支,专用分支等将由请求或执行它们的人管理.为什么你或同事"A"关心同事"B"分支主线以及时发展他的实验性特征？同事"B"通过开发一些开创性的东西,负责他的分支并使其与主线保持一致.要么不断地将主线的变化合并到他的分支,要么在重新整合他的新代码之前.如果您想了解更多,研究集成分支.
至于工具集..在SVN(Jira,trac,mantis,redmine ..)中可以很好地整合的任何bugtracker应该可以胜任.但我不明白这部分问题与你的冲突问题有什么关系.
3. 即使我的公司采用扁平化管理方法,像我这样的新秀如何能够在不打破无形"高级"等级的情况下说服或强制与高级程序员进行社交沟通？
我认为你高估了油井工作流程所需的沟通量.你提到的内容表明你的公司缺乏一个工作流程,在这个工作流程中,你可以在根本上对抗冲突(参见1.和2.),在这种情况下你需要进行更多的沟通,可能会产生不必要的高额开销.拥有CMS或某种"我在这里工作"的标记系统可能仍然值得继续.
你表示,即使在他们应该做得更好的冲突案件中,一些高级开发人员也不喜欢谈论或社交.不要让他们通过合并为他们逃脱.合并应由分支所有者完成.当冲突发生时,至少有一个冲突方必须决定变化.理想情况下,双方一起坐在差异上,但不是第三方最初不涉及有关来源.解决冲突失败(选择错误的更改)可能会导致构建破坏,甚至更糟的是未检测到的错误.人们需要意识到.
如果高级开发人员"A"(合并主线变成他的分支)诅咒冲突但不与高级开发人员"B"交谈,他们的主线变化与他的冲突,那么担任调解员并不容易.如果它不是为你划线,请尝试与开发人员B交谈并说服他接近A以更快地解决冲突并减少错误.
但最终它是开发者"A"的责任,而不是你的责任.你似乎已经向你的同事举了一个例子.如果这还不够,请尝试小心地指出,没有足够的通信是构建中断的原因.也许可以私下和一位大四学生讨论你的想法,开放但不要辱骂."我们可以更好"听起来比"你们做错了"更好.而对于你作为一个年轻的专业人士,句子如"如果你告诉我什么时候与你的代码发生冲突我觉得我的代码会更好"可能比"当你得到合适的人时要求第二双眼睛"更合适冲突",即使后者更直接.
如果这一切都无济于事,您可以考虑与您的老板或团队负责人讨论您遇到的障碍.如果他不是傻瓜,他/她会听.
用于分支和标记
1. 我不希望其他团队分支在程序中添加"Hello,World!"代码.我想把分支视为一种与众不同的东西.任何人都可以给我一个关于何时添加创建分支的经验法则？什么时候合并？
合并请参见下面的问题4.
对于分支:你完全正确地试图拥有尽可能少的分支.分支是有代价的.复杂性,合并开销等我倾向于坚持"分支不兼容的政策".你问什么政策？您的每个主要分支都应附加一组记录的规则.
例子:
你看到有3个虚构的分支和一个标签."feature-apirefactoring"是正确应用"不兼容策略分支"的示例.
应通过分割不同类型的开发活动来使用分支来降低风险并提高效率.分支政策单独定义了可接受的发展和风险潜力.希望你的后备箱更稳定？定义新策略"不要引入W3C验证器警告".如果开创性的开发工作为了效率而必须打破这个规则或者提供快速的概念验证(我们先破解并稍后清理),它就是它自己的分支的一个很好的候选者.
每当您或同事感到违反规则的冲动时,因为不遵守既定政策会更简单或更安全,您就可以很好地讨论分支创建.
2. 在什么情况下分支的一个分支是一个好主意？ 上面回答我认为:).
我遇到的一些例子:
还有十几个.您的政策越精细,您的分支就越具有异国情调.
3. 对于标记,我的理解是标记符号表示程序的静态点(即:v1.0,v2.5)是正确的吗？
是.对于subversion,它可以被描述为别名."/tags/1.7.2"可能是项目的状态,因为它是在修订版30932.您可以在某个版本准备就绪时记下修订版号,并将您的新资源与其进行比较或创建此旧版状态的结帐.或者您可以使用更容易记住的标记名称.
subversion中的标记也只是一个不接收任何提交的分支.
4. 如果我创建一个分支并开始编写我的更改,我的队友应该从我的分支开始同步吗？还是他们还应该在后备箱里发展？或者他们应该为自己创建另一个分支？
简短的回答:当你不确定时,使用主干并且根本不合并(同步,推,拉).
答案很长:在一个理想的世界中,不需要分支机构,因为所有开发人员都会在发生变化时立即获得团队检查的所有更改.在理想的世界中,这些变化不会与任何开发人员自己的未提交工作发生冲突.无论开发人员在我的理想世界中检查什么,也是完全正确的,没有缺陷和故障.
唉,程序员世界并不完美.因此,您创建分支以保护自己免受同事所做的更改,或者您将更改隔离到不会弄脏干净的主线,有时两者都是如此.
变化的方向(你的同事从你那里拉出来或你从你的同事那里拉出来)取决于分支机构预期的风险.将"拉"(合并)更改签入发布分支的风险是多少？查看上面定义的策略,它应该只是错误修正.风险似乎很低.对于大多数发布分支场景,从它们合并到turnk是绝对必要的,因为你必须在从trunk创建下一个release-branch之前手动重新修改bug.
破坏自己宝贵的工作或不得不改变自己的代码的风险有多大,那就是将功能优化的变化合并到你的行李箱结账中？你可以开发新的功能,增强api-call你的同事拥有功能分支决定用一个完全新的实现替换.这可能会扼杀情绪.
豆腐秤
我认为来自perforce的聪明人首先提到了"豆腐"规模.(您可以谷歌或阅读这些幻灯片http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf).
除了每个分支机构的政策外,您还可以估算出它们的"坚定性"以及它们在豆腐规模上的地位.
功能分支是"软"的,因为它处于恒定流量,没有经过良好测试,并且远离任何付费客户的眼睛.因此它也更能够吸收变化.如果事情破裂,你希望他们打破"软"分支.
你的主干将是"中等"的,因为它不是发布准备好的,而是比一些远程功能分支更好的测试.(更不用说因为更多开发人员检查主干而不是功能分支).如果在没有正确集成的情况下在主干中出现巨大的兼容性破坏性变化,它可能会分散开发人员的注意力,但正常大小的签到可以很好地浸泡.
发布分支机构属于"最坚固"的分支机构,因为它们已经完善,经过测试,有时只需几小时即可完成生产使用.如果你打破这片"豆腐片",缝合在一起会更痛苦.另一方面,您可以更好地了解您在此分支机构中所提供的内容以及更高的信心(如果不是单元测试证明)它运行良好.
你应该按照它们在豆腐上的位置来订购树枝.底部柔软,顶部坚固.
最好的做法是"合并,复制".
更妙的是"向下合并,复制了在稳定状态 "
合并:
"复制":
最后但并非最不重要的是阅读此最佳实践文档.再次由perforce人;)http://www.perforce.com/perforce/papers/bestpractices.html
搜索stackoverflow或查看我的个人资料,了解更多与SVN相关的问答.
哦,知道你如何成功实现你的合法野心会很好.
周末愉快
C