我们有一个StarTeam视图,其中有两个处于"未知"状态的文件 - 是否有人理解为什么他们处于这种状态和/或我们如何让他们离开状态?
是删除它们并使用其他名称重新添加它们唯一的解决方案?
请注意,如果您检查这两个文件(定期或使用"强制结帐"),它们将始终列为"未知"(烦人).
谢谢.
更多信息基于Craig的建议如下:
a)使用MD5校验和计算文件状态:相同的结果("未知"状态)
b)这两个文件在服务器上只有一个版本.我不确定这是不是因为我们的CM小组试图通过删除和重新创建文件来解决问题,或者是否真的只有一个版本.这些文件是文本文件.
c)我尝试删除本地计算机上的文件并刷新状态.当我这样做,而不是看到列出为"未知"的两个文件,我看到总共有四个文件列出状态为"丢失".每个文件都列出了两个条目 - 每个条目具有相同的文件名,文件夹路径,"修改者"和"签入时的文件戳".我不知道为什么每个文件都列出两次.如果我选择一对中的每个条目并选择"比较内容",我的差异工具说它们是相同的.
无论是使用MD5校验和比较还是非MD5,我对这四个文件都有同样的奇怪问题.
如果我尝试检出所有四个丢失的文件,我会收到两个警报,提示我合并文件.我说不,文件现在在我的本地文件系统上,状态又回到我开始的位置 - 两个文件列为"未知".
克雷格的更新:
你肯定是在做点什么.我将每个重复的项目移动到另一个目录.这立即解决了这个问题,因为我现在可以在没有任何"未知"项目的情况下签出四个项目(两个在同一个目录中,两个在新目录中).然后我删除了我移动到新目录的两个项目.
在这样做的过程中,我看到了更多信息.我们不知何故有这样的目录结构:
Parent_Dir --SubDir1 --SubDir1 --SubDir1 --SubDir1 <- Two items were here --SubDir1 <- Two items were here --SubDir2 --SubDir3 --SubDir4 --SubDir5
不知何故,我们有五个具有相同名称的子目录,这两个文件存在于两个具有相同名称的子目录中.
问题似乎已得到解决.你认为我应该手动删除额外的子目录吗?
感谢Craig这个问题似乎已经解决.我不知道这种情况是如何产生的(任何人?)但是......我们现在很好.谢谢克雷格!
在确定问题所在之前删除文件将是一个巨大的错误.删除和重新添加文件会导致历史记录和文件的任何链接中断.由于StarTeam在内部的工作方式(无论如何都使用Native-II存储库),它也可能无法解决问题.删除文件并重新添加相同的文件实际上不会更新存储库中的任何内容,除了指向该修订的指针.当您删除文件时,修订本身将保留在那里,重新添加它只会创建一个指向该修订的新指针.
如果您还没有这样做,我强烈建议告诉StarTeam使用MD5校验和计算文件状态.在客户端通过工具 - >个人选项 - >文件 - >使用文件校验和来计算状态.然后再次尝试更新状态.这不是默认设置(至少在某些版本的StarTeam中),所以值得检查.如果您还没有这样做,它本身可能会解决问题.
首先要确定修订版本是否在服务器上有效.如果文件是文本,最简单的方法是比较该修订版与先前版本之间的内容.如果确实证明修订版已损坏,那么最好的解决方案是检查早期修订版,然后强制签入.这样就可以保留文件的历史记录.
如果文件在服务器上显示为OK,则通过比较内容在本地测试它.如果文件在本地损坏,请随意在本地删除该文件,然后再次检出.与删除服务器上的文件不同,除了本地修订外,您不会丢失任何内容.
如果这些建议无法解决问题,我仍然不建议删除服务器上的文件.告诉我你在这里的调查结果,我们会看到我们可以从那里去的地方.在我看来,几乎总是错误地杀死历史.
根据帖子中的更新信息,我可以更好地了解这里发生了什么.可能有两个项指向同一个文件,并且具有相同的名称."项目"是StarTeam中的一个概念,涉及单个文件,变更请求,要求等可以同时存在于多个位置的事实.例如,您可以在两个不同的视图或项目中拥有单个文件.
通常,您在同一文件夹中没有具有相同名称的项目.但它可能发生.这可能解释了"未知"状态.当您告诉StarTeam将磁盘上的文件与服务器上的同名项目进行比较时,可能无法确定应该查看哪个项目.
我要尝试的第一件事是尝试将其中一个项目拖到其他地方.如果这样可以解决相关文件夹中的问题,则可以在其他位置删除该项目,而不会影响文件夹中的项目.另一方面,如果拖动其中一个项目导致它们都移动,则很容易将项目拖回到它们来自的位置.
你认为我应该手动删除额外的子目录吗?
是的,但与文件一样,首先移动它们,并确保在删除它们之前,您想要保留的子目录不受影响.