Capturing deleted file history?

[tobocop2]

@charleso

I know that this is listed as one of the problems in the problems section so once again, perhaps it makes no sense as an issue and you can close it. This tool is perhaps one of my favourite discoveries thus far and I am really trying to migrate some code with history to git rather than abandoning all of the history. However, being unable to keep proper track of deleted files is a major drawback and would make the history incomplete and partially unusable.

Currently, files that are deleted are not tracked throughout the conversion. As you mentioned, there is no way to revert to an old version that references a deleted file. The lshistory generates output like the following (or similar, this is off the top of my head):

Uncataloged file: Somethign.cpp
Uncataloged file: AnotherThing.h

In between the checkinversion and checkindirectory sections. You mention in the problems section that you need to adjust the config spec. Would you mind providing further advice / clarification here?
Would I need to iteratively set the config spec since the beginning of time to properly capture history for files that are not in my view?

I greatly appreciate the advice.I hope you don't mind passing on some of your clearcase wisdom via these github issues.

[charleso]

@t-g-p I'm afraid I can't remember the clearcase behaviour all that well, and I don't have a clearcase instance to try anything with so I'm not much use. Regarding the uncataloged file, do you have a version and way to run a cleartool get with the previous version of the directory and file?

I'm sorry I can't really help and that I didn't document the whole thing better when it was fresh in my mind all those years ago. :(

[tobocop2]

@charleso

I can probably find the release that contains that file and extract label info and revert to that. Also, I noticed in the rebase module you're calling lshistory with -recurse. Do you recall the reason why you used that flag in place of the -all flag? I know that they are mutually exclusive.

It looks like with -all, you can get information about deleted objects?

http://www-01.ibm.com/support/docview.wss?uid=swg21245108

[tobocop2]

@charleso

So i think that the only way to get the full history would be to do the following:

Find all versions of a directory.

for each version of directory: 
    Load the config spec for each version. 
    Get all history. 
    If directory has a directory recursively apply the same strategy. 

[charleso]

@t-g-p Sorry for the delay.

I don't know that I ever knew about or saw -all. It seems like a massive oversight. If it does return the deleted files then I don't think you need to change the config spec unless I'm missing something. What you do see from the lshistory for deleted files? What happens if you change git-cc to just use -all?

FYI you can always test git-cc by pointing to a sub-folder in clearcase if you want to test something quickly without having to wait for the entire history for everything.

[tobocop2]

@charleso

I've been using a small folder for testing out of necessity haha.

Anyway, the -all flag doesn't do what i thought. I think capturing deleted file history is very far from trivial.

You'd need to set your config spec to point to every version of a folder and run this tool. If the folder has a deleted folder, then you'd need to do the same for that folder..and recursively.

Once you get the git history for all the versions possible, I guess you then need to rebase them all together?

I'm hoping that i don't need to go this route, I am personally fine with just having a complete history of everything that is available in the vob. If I have to capture deleted history, the clearcase to git transition will potentially not happen anytime soon. I'm unsure how to handle the merging of every git history for every version...I see the uncataloged file message, I need to treat that as a git rm.

Also you have a comment saying that files that are renamed without any changes is tricky. Do you recall why this is by any chance?

[charleso]

@t-g-p

Anyway, the -all flag doesn't do what i thought. I think capturing deleted file history is very far from trivial.

:(

You'd need to set your config spec to point to every version of a folder and run this tool. If the folder has a deleted folder, then you'd need to do the same for that folder..and recursively.

Yeah that's what I thought. That would be very slow I imagine. I'm not sure it would be worth it.

Also you have a comment saying that files that are renamed without any changes is tricky. Do you recall why this is by any chance?

This is the commit where I made the change to support it, and amazingly I actually wrote a commit message that explained what I was thinking at the time.

da9a4ca

It's because the rename only happens at the directory level. For the most part git-cc relied on change events to files to create and update them in git . But if the file is only renamed then we have to inspect the directory history to guess what version of the file was kept. If you want a better feel for this I suggest looking at the lshistory of a rename to see what I mean (I really wish I'd checked in some examples and tests at the time, I could just point to them).