【问题标题】:How ClearCase identify hijacked files?ClearCase 如何识别被劫持的文件?
【发布时间】:2015-02-02 21:31:14
【问题描述】:

有人说被劫持的文件是“只读”标志已被删除的文件。

我尝试删除“只读”标志 (Windows),但 ClearCase 无法将其识别为被劫持。然后我尝试使用 Cygwin touch 文件而不实际更改任何模式标志。这一次 ClearCase 警告我,我们被劫持了!

ClearCase 似乎只查看文件的时间戳而不是它们的内容,而不是它们的只读标志。当与 git 并行工作时,这种机制有一个非常糟糕的副作用。例如,如果我这样做:

 git checkout bar
 git checkout master

它与以下内容相同:

 touch foo

因此,ClearCase 会认为foo 被劫持,但事实并非如此。对于大型项目,这将是非常戏剧性的,不幸的是我总是使用 git 在我的快照视图中快速来回切换。

在我的情况下,什么是好的解决方案?

编辑

这是一个更危险的例子:

 stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
 echo "ClearCase will not see this" >> foo
 source restore_timestamp
 rm restore_timestamp

【问题讨论】:

  • 底线:不要在 ClearCase 视图中执行 Git

标签: clearcase


【解决方案1】:

当我在 ClearCase 和 Git 之间并行工作时,我不会触及 ClearCase 中的 git 存储库:我将它克隆到其他地方并从那里开始工作。

实际上,我没有直接在 ClearCase 视图中创建 git repo in:我在外部创建它,将 ClearCase 视图中的所有文件添加到其中(仅用于初始添加:@ 987654322@)

当需要将 ClearCase 快照视图与 git 工作树同步时,从该工作树到 ClearCase 视图执行 clearfsimport (as in this answer):仅将修改后的文件签出/更新并签入。

这样,我就完全绕过了“被劫持/未被劫持”的问题。

【讨论】:

  • clearfsimport 在我的情况下是一个非常糟糕的解决方案,因为它需要在自己的分支上工作。没有自动方法可以快速从 dev 分支的最新点创建分支,在此分支上执行 clearfsimport,在 clearcase 上执行合并,同步回快照视图。
  • @coin "clearfsimport 在我的情况下是一个非常糟糕的解决方案,因为它需要在自己的分支上工作":不需要分支。 git repo 反映了 CC 视图,这意味着两者在概念上都在同一个分支中工作。 clearfsimport 解决方案。
  • 我将在一个新问题中详细说明我的最后一条评论,因为这是另一个主题 :)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-10-01
  • 1970-01-01
  • 2015-08-25
  • 1970-01-01
  • 2011-07-11
相关资源
最近更新 更多