【问题标题】:Understanding Label limitations了解标签限制
【发布时间】:2012-04-02 04:36:08
【问题描述】:

blog 状态

标签带有一个很大的警告 - 标签本身不是 版本受控,这意味着无法跟踪或审核 标签上的活动历史。另外,标签不会保留 文件删除时的版本,所以如果文件被删除,任何 依赖于该文件版本的标签本质上是软管。

这不是我阅读有关 TFS 标签的类似信息的唯一地方。缺乏历史是很清楚的。第二部分“标签不保留版本的副本......”不清楚。事实上,我创建了一个测试项目 > 标记它 > 删除一个文件 > 执行按标签获取,文件又回来了。那么这是指什么呢?最近 TFS 中的标签功能是否发生了变化?

我意识到文件删除实际上并没有删除历史记录,这是原因吗?换句话说,如果我运行

tf destroy "$/MyTeamProject/Project/FileName.cs"

这就是删除文件的意思吗?如果是这样,这似乎是一个值得考虑的特殊情况。我的意思是,这是对历史的故意不可恢复的删除。在这种情况下,变更集不会对标签有任何改进。

【问题讨论】:

    标签: tfs


    【解决方案1】:

    当我们将标签应用到某个时间点的源代码控制版本时。直观地说,因为我们最初在某个时间点创建了源代码控制的快照,所以可以假设该快照代表某个时间点的源代码。

    这是不正确的。标签可以在创建后进行编辑。

    从概念上讲,标签定义了产品和产品的错误修复 (source)。一个真实世界的例子可能会有所帮助。假设我们有一个名为 AlphaBoogerBear 的产品。 AlphaBoogerBear 是一个产品,而不是一个版本(想想预发布的 Windows 名称)。 AlphaBoogerBear 可以做成一个Label,AlphaBoogerBearLabel。我们执行 AlphaBoogerBear 的发布。有一些错误。我们修复它们。

    现在,我们返回并编辑 AlphaBoogerBearLabel 以包含错误修正。标签不再代表某个时间点的快照。相反,它代表了 AlphaBoogerBear 的最稳定版本。

    最后,我们转向 BetaBoogerBear。我们可以选择返回并及时获取代表旧产品最佳版本的标签。

    在我看来,如果需要源代码控制版本的快照,最好进行分支。如果需要一个代表产品发布的可编辑快照,那么标签很有用。尽管如此,这似乎是信任和便利之间难以平衡的问题。

    至于作者的意图,我真的不能肯定。他可能的意思是说可以从标签中删除项目,因此当您按标签获取时,项目将消失。不过,该项目仍存储在 TFS 历史记录中,因此尽管情况令人困惑,但并非所有内容都丢失了。

    【讨论】:

      【解决方案2】:

      我不确定关于标签受文件删除影响的句子是什么意思。但你说得对,常规文件删除不会影响标签,但销毁会。

      关于不受版本控制的警告是,有人可以通过在标签中包含或排除文件或更改标签中包含的文件的版本来编辑标签。并且标签定义不会有这些更改的历史记录。

      【讨论】:

        【解决方案3】:

        据我了解,TFS 中的标签基本上是变更集的集合/集合。

        假设您标记了一个目录,其中包含两个文件。该标签将包含三个变更集:一个用于目录,一个用于每个文件。在 TFS 中删除其中一个文件将为目录生成一个新的变更集,因此在此阶段执行按标签获取将“返回”已删除的文件,因为它包含删除之前的变更集。 销毁一个文件会将它从它出现的任何变更集记录中删除,因此也会破坏标签中的信息。

        由于标签仅由其名称标识,因此也很容易用新标签覆盖它,从而破坏旧信息。该命令的/child 参数可以稍微改变这种行为:使用/child:merge 将保留先前记录的变更集和新的变更集,/child:replace 将用新的变更集交换旧的变更集。在上面的示例中,这些替代方案都不会产生任何影响,因为按标签获取仍然会检索最高的变更集。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2017-09-24
          • 1970-01-01
          • 1970-01-01
          • 2020-07-29
          • 2020-09-25
          相关资源
          最近更新 更多