在不常见的情况下, 我们往往需要在团队项目之间迁移更改.在推荐的情况下, 同一个codebase的所有不同版本或者branch的源代码要放在同一个团队项目下, 这样方便源代码的分支/合并操作, 也同样方便工作项和代码更改集的关联. 但是, 在某些公司特定策略也可能是历史遗留策略的要求下, 在TFS上, 往往带来不好的实践. 比如, 给某些特定版本的源代码创建单独的团队项目来管理, 使TFS本身的合并分支操作难于在Team Projects之间进行, 必须特别注意.
让我们来简化场景.
老板对你说, "我们有一个已经存在的项目SunPoject保存着我们的项目代码 Version 1.0. 现在1.0项目接近完成, 2.0版本马上就要开始开发. 公司的源代码管理策略是每一个Major版本数字改变, 这需要一个新的团队项目. 新的团队项目的源代码由前一个主版本的当前主分支提供", "小A啊, 这个事情不难吧? 你顺手完成了吧."
我们有两种方法来完成这一任务, 在创建新的团队项目时, 有一个不起眼的选项或许我们经常会忽略, 但是这个选项直接决定了在以后的工作中, 分支/合并操作的复杂度.
操作1, 如果选择"Create a new source control branch"并且选择源团队项目, 新的团队项目将会被创建, 源代码也会自动被Branch到这个新的团队项目中.
操作2, 如果选择"Create an empty source control folder", 一个空的根目录会被创建. 然后我们可以在原来的团队项目上选择Branch操作, 让源代码转移到这个新的团队项目中.
二者的最终结果似乎是等价的?
等等...事情似乎没有这么简单...
第二个场景, 过了一段时间, 老板又对你说(老板总是说啊说的), "小A啊, 我们在1.0的团队项目上面做了几个HotFix", "你是不是现在把这些HotFix合并到我们正在开发的2.0团队项目上?", "就是一个Merge操作, 不难吧?"
于是你打开了Team Explorer, 在1.0项目上选择Merge, 这个时候差别显现了,
现象1, 如果上一步你选择了步骤1, 那么你会看到, Target Branch里面有你新创建的团队项目, 你可以从容选择HotFix对应的那些ChangeSet, 做Merge操作.
现象2, 如果上一步你选择了步骤2, 那么你将看到, Target Branch的选择列表里面, 没有你想要的新团队项目!!!因为在创建新项目的时候, 新旧项目没有对应的分支关系!
那么如何在独立的团队项目之间迁移更改呢?
TFS的分支合并给了我们两个选择, 基于命令行的操作和基于UI的操作.
幸运的是, 我们可以使用基于命令行的TFS Baseless Merge 命令来完成这一任务.
tf merge /baseless -r “$/Project2/Main/Source” “$/Project1/Main/Source”
- tf merge - Team Foundation的merge命令
- /baseless - 指示Baseless Merge的开关.
- -r - 对子目录进行递归的合并
- “$/Project2/Main/Source” - 源服务器目录
- "$/Project1/Main/Source" - 目标服务器目录
这样就可以进行merge了, 不幸的是, 由于项目间对应的分支关系的缺失, 以后你的每一次Merge操作, 都只能基于命令行了...