我有一个发布分支(RB,从C5开始)和trunk(C10)上的变更集,我现在想要合并到RB上.
该文件在C3处变化(两者共用),一个在RB上的CS 7中,一个在C9(中继)中,一个在C10中).因此,我更改的文件的历史记录如下所示:
RB: C5 -> C7
Trunk: C3 -> C9 -> C10
当我将C10从主干合并到RB时,我希望看到一个合并窗口显示我,
C10 | C3 | C7因为C3是共同的祖先修订版,C10和C7分别是我的两个分支的提示.但是,我的合并工具告诉我C10 | C9 | C7.
我的合并工具配置为显示%1(OriginalFile)|%3(BaseFile)|%2(Modified File),所以这告诉我TFS选择C9作为基本修订版.
这完全出乎意料,完全违背了我在Mercurial或Git中使用的合并方式.我有什么问题或是TFS试图通过合并让我疯狂吗？
这是默认的TFS合并行为吗？如果是这样,您能否提供有关他们选择以这种方式实施的原因的见解？
我正在使用TFS 2008和VS2010作为客户端.
我们使用Team Foundation Server并拥有大量ASP.NET Web应用程序项目.每个Web应用程序都使用我们内部开发的自定义内容管理系统.CMS本身就是一个ASP.NET Web应用程序.
部署后,CMS驻留在子目录中,例如"/ Admin".CMS由.aspx和ascx文件组成,相应的程序集当然放在bin中.
目前,CMS文件分别存在于源代码管理中的每个Web App.换句话说,每个依赖于CMS的Web应用程序中都存在"Admin"文件夹.这带来了明显的挑战,因为必须将对CMS的更新分发到每个依赖站点.我的工作是自动化/简化流程.
我们目前不执行任何自动构建.我对TFS中的源代码控制分支知识有限,我不确定它是否适用于这种情况.确保依赖项目从CMS项目接收最新程序集和标记的最佳方法是什么？提前致谢.
听起来像#2(来自'bamboo)是我追求的解决方案.鉴于共享代码已经存在于每个单独的项目中,您是否可以简要描述我将进行"分支/共享"CMS的过程？此外,值得注意的是,我不希望.cs文件传播到依赖项目,只是标记和程序集.这会改变策略吗？我应该首先在共享项目上创建一个构建事件,以将必需的文件复制到"Release"文件夹,然后分支Release文件夹吗？