1

One says an hijacked file is a file where the "Read Only" flag has been removed.

I tried to remove the "Read Only" flag (Windows) and ClearCase does not recognize it as hijacked. Then I tried to touch the file using Cygwin without actually changing any mode flags. This time ClearCase warns me, we've got hijacked!

It seems ClearCase only look at the timestamp of files not their content and not their read-only flags. This mechanism has a very bad side effects when working in parallel with git. For example, if I do this: 

 git checkout bar
 git checkout master

It would be the same as: 

 touch foo

Thus, ClearCase will think foo was hijacked which is not the case. For huge projects, this would be very dramatic and unfortunately I always use git to quickly switch to back and forth in my snapshot view.

What would be a good solution in my case?

EDIT

A much more dangerous example would this one: 

 stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
 echo "ClearCase will not see this" >> foo
 source restore_timestamp
 rm restore_timestamp
nowox
  • 25,978
  • 39
  • 143
  • 293

1 Answers1

1

When I work in parallel between ClearCase and Git, I don't touch to the git repo within ClearCase: I clone it elsewhere and work from there.

Actually, I don't create a git repo in the ClearCase view directly: I create it outside, adding in it all the file from the ClearCase view (using just for the initial add: git add --work-tree=/path/to/CC/view)

When it is time to synchronize the ClearCase snapshot view with the git working tree, a do a clearfsimport (as in this answer) from that working tree to the ClearCase view: obnly the modified files are checked out/updated and checked in.

That way, I completely bypass the "hijacked/not hijacked" issue.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • `clearfsimport` is in my case a very bad solution because it requires to work on its own branch. There is no automatic method to *quickly* create a branch from the latest point of the dev branch, do the clearfsimport on this branch, do the merge on clearcase, sync back the snapshot view. – nowox Feb 02 '15 at 13:34
  • @coin "clearfsimport is in my case a very bad solution because it requires to work on its own branch": no branch needed. The git repo reflect the CC view, meaning both are conceptually working in the same branch. `clearfsimport` is *the* solution. – VonC Feb 02 '15 at 13:36
  • I will detail my last comment in a new question cuz this is another topic :) – nowox Feb 02 '15 at 13:38