小编Dan*_*kas的帖子

发布周期的分支源是常见的源管理方案之一.尽快合并是一种很好的做法.因此,我们有一个人为因素:分支已关闭,但有人忘记将某些内容合并回主干.

问:是否有"一键"方式来获取未从分支X合并到主干的所有修订号？

(注意:我不需要这些修订号来找到要合并的内容,我需要它们来创建自动验证,这会提醒人们确保他们不会忘记将某些内容合并到主干.合并本身不是问题.)

似乎svn mergeinfo命令在这里没有帮助.如果不在根级别执行合并,则传递分支和主干根将失败(这是常见的情况).

脚本,工具任何类型的svn钩子作为解决方案是受欢迎的.

PS

最新版本的SVN.无需争论这种情况有多普遍或好;)

要执行敏捷项目,首先需要一份合同.没有合同 - 没有项目!没有项目 - 没有敏捷,SCRUM或任何东西!

如果我们谈论大中型项目,合同必须有明确的安全触发器.即客户希望非常肯定,如果我们同意在时间上结束项目= T,预算= B和范围= S,我们最终不会以时间= T×2,预算= B×3或范围= S/2.

另一方面,作为提供产品的公司,我们不希望项目意外结束.即如果经过一番迭代,客户说"现在我发现这实际上就是我们所需要的.我们现在停下来." 这个项目计划再过2个月,而不是没有计划工作的人.如果3-6人不是一个大问题,15-25可能是一个真正的问题!

然而,我没有找到任何具有安全功能的合同的真实示例,这将允许项目以完全敏捷的方式执行(声明或未向客户声明).我在许多论坛上找到的标准说法 - 与客户交谈,向他解释这是一种更有成效的工作方式等,并不能说服我和我的管理层.并不是说我们不相信敏捷实际上是一种更好的方式.只是安全触发器中的差距是如此明显,以至于我们的客户都没有买它而且我们不喜欢它们(差距,而不是客户;)).

请不要"它可能会以这种方式工作......" - 我已经阅读了大量的内容.只对"为我们这样工作"感兴趣.毫无疑问,跳过所有自信的信息.

PS据我所知,标准迭代,特征驱动的方法建议客户在每次迭代(迭代次数)后付款,并且能够在任何迭代之后由客户和项目执行者停止项目而不会过多地说明后果,而不是说"无论如何都会失败,所以越早越好"(这是正确的,但在签订合同时并不是很有帮助).

每个文件的代码行,每个类的方法,圈复杂度等.开发人员抵制并解决大多数(如果不是全部的话)!有一篇很好的Joel文章(没时间找到它).

您建议使用哪些代码指标来自动识别"糟糕的代码"？

什么可以说服大多数(你不能说服我们所有人一些糟糕的指标!:O))开发人员认为这个代码是"废话".

只有可自动测量的指标才算重要!

我需要一个select from table,它没有列告诉我何时插入行,只有timestamp列(值如:0x0000000000530278).昨天有些数据导入到表中,现在我需要找出导入的确切内容:(

有没有办法只使用timestamp信息？在这里我发现:

• 时间戳是一个8字节的连续十六进制数,与日期和时间无关.
• 要获取时间戳的当前值,请使用:@@ DBTS.

也许有办法找到timestamp特定时间周围的价值？这将有助于形成一个选择.或者也许有一个众所周知的解决方案？

我记得SVN历史上有2个事件:TortoiseSVN可用,VisualSVN可用.

第一个结果:"我们永远不会想要在命令行中使用SVN".第二个结果:"没有VisualSVN我们永远不会使用SVN和MSVS"

请理解这是正确的 - 如果我们需要使用Tortoise无法实现的东西,我们会使用SVN命令行,如果我们需要的东西不能从MSVS获得,我们会使用Tortoise.但除此之外(99.9%的时间),您所需要的只是在IDE中.

现在我明白并且喜欢分布式源代码控制的好处,但我根本无法在IDE中重命名文件并手动执行hg重命名以免丢失历史记录("删除+创建新"而不是"重命名"=没有历史记录).我也不认为责备或文件还原为无法直接在解决方案资源管理器中选择的文件上执行或打开进行编辑的操作.使用VisualSVN所有这些,以及更多,只是工作!

DSCM的概念优势很棒,但如果IDE无法提供日常使用的简单功能,那么这些功能并不好!

问题是:是否有一个带有插件的分布式源代码控制,它像VisualSVN一样顺利集成到MSVS中？Git Extensions和VisualHg目前还没有接近这一点,VisualSVN团队拒绝创建VisualGit:

" 只有当Git将其许可证从GPL更改为BSD/Apache风格以允许衍生商业工作时,我们才能考虑此选项. "

PS必须来自IDE:

• 解决方案树中的文件状态.如果编辑了任何子项,则将父项即文件夹/项目/解决方案标记为已编辑.
• 上下文更新,提交,历史记录,责备,还原为解决方案资源管理器/打开文件中的单击操作,并提供键盘快捷键!
• 自动跟踪和处理文件重命名/拖放/新文件创建.
• 在编辑文件中尚未提交的内容的指示符(黄线)在文件关闭并重新打开后不会消失.

不是很多吗？

更新:

1)昨天测试了HgSccPackage.它肯定有更多所需的功能可以从IDE,它们确实尊重当前上下文,即选择/打开文件等.不幸的是它的解决方案树状态目前是错误的,不支持文件夹状态.

2)在与VisualHG相同的回复中提到的Git源代码控制提供程序至少缺少两件事:

• 由于某种原因,他们有很少的上下文行为(例如责备/注释是NA)
• 它接缝它们都是基于MSVS源代码控制API(与VisualSVN不同),因此不提供解决方案文件夹状态(与HgSccPackage相同).

3)Charles Bailey指出,无论如何git处理重命名.是的,确实如此.这里不需要任何IDE支持(不确定mercurial).所以git MSVS支持只缺少良好的上下文,一键动作和正确的树状态支持(还有一条黄线,但是让我们说它非常好,但目前还不是必须的).

自动化测试必须能够快速反映实时项目状态.这个想法是:

1. 在执行任何提交到存储库自动构建之后(尽可能快地完成).
2. 如果构建成功,则启动自动化测试.一定要快.

这是我知道的最好的方法,以确定您的更改是否会破坏任何内容.

起初,似乎快速进行构建很难,但我们设法将它保持在100秒左右.105(!)项目的解决方案(MSVS 2008 C#).

测试似乎并不那么简单(我们使用NUnit FW).单元测试不是一个大问题.正是集成测试杀死了我们.而不是它们更慢的事实(关于如何使它们更快的任何想法都非常受欢迎)但事实上必须设置更慢(大约1000秒)的环境!

我们的集成测试使用需要重新部署的Web/win服务(目前为止19个),以反映最新的变化.这包括重新启动服务和大量HDD R/W活动.

任何人都可以分享环境和工作流程应该/可以组织/优化的经验,以加强自动化测试阶段.什么是"低级"瓶颈和解决方法.

PS书和广泛的文章是受欢迎的,但现实世界的工作解决方案更受欢迎.