0

We just migrated from TFVC, with the git tfs tool.

We did use this command line :

git tfs clone $tfsServer $tfsRepository . --branches=all

Which is supposed to take all our branches and import them in a git repo.

We had no errors and everything seems to work fine. I did a git clone of my repository, and I had some things that was not building on one of the branch(but was on TFVC).

I checked, and some files were not containing some changes. So I did check the history of this file and I see that every commit of TFVC is present, and I see that the latest commit contains the modifications(one constructor now receives an object and not an int anymore).

I'm not sure what happened, and what can I do to resolve this issue, if possible, for the whole repository.

It's kind of critical because guys here have started to work on the new repository.

EDIT

It's really weird, in bitbucket server, when I go to the specified file, I see that this file has been commited the 23 feb 2016, but the version of the code is the one of the previous commit. Also, when I'm on this page(where I see the not-up-to-date code), and I click "Diff to previous, I see that the expected changes have been made.

EDIT 2

I made a Winmerge check between my TFVC and my GIT repository, and I've like 60 differents files. Not sure what to do now...

J4N
  • 19,480
  • 39
  • 187
  • 340
  • does the "path" to the file match 100% between TFS and git? did you use branches in TFS? were that missing-changes made on some branch? when you imported/converted, did it cover whole reportitory or just some roots/branches? did you have multiple branches in GIT right after the import/conversion, or, if you don't remember, do you now have any branches in GIT? when you compared GIT code to TFS code, have you tracked specific branch in git to original branch in tfs, or just compared git/master with code from your tfs workspace? ... ok, that's for starters – quetzalcoatl Feb 13 '17 at 12:26
  • why do I ask: I have no idea how accustomed to GIT you are, but GIT uses a *different* branching concept than TFS does. In TFS, like SVN, a "branch" is a half-intelligent folder in the tree that contains a copy of another folder. If you download them all, you will get multiple branches on the drive at the same moment of time. In GIT, it is NOT that case. In GIT, at any point of time, whole working copy (the "workspace" with all files) present an image from only a single branch that you currently selected to work on. It's quite likely that in GIT and TFS you are looking at different branches – quetzalcoatl Feb 13 '17 at 12:30
  • so.. try to answer questions from my first comment, just see that for yourself, and then check if you fetched correct branch on git side. Also, git-tfs utilities usually leave a comment note on every imported commit and that note tells you which TFS-commit-number did it come from. Visit every similar branch on GIT side, check those notes on the a few commits most-recently-imported-from-tfs and that should tell you exatly what git-tfs pulled and how it was interpreted as which branches on git side – quetzalcoatl Feb 13 '17 at 12:41
  • @quetzalcoatl : Yes I've branches on TFS, and the two paths are EXACTLY the same. The branches present on TFS were imported in GIT, and it's on one of those branch that I've this issue. I compared the version of the GIT branch(I did checkout the branch) and the one of the TFS branch(Basically, I compared `TFS_REPO/Branches/MyBranch/Src` against `GIT_REPO/Src`(and I had switched to the appropriate branch before). I'm really 200% sure that I'm on the correct branch on the two sides, and I understand well the difference(even if I don't master every file contained in the .git directory). – J4N Feb 13 '17 at 12:58
  • Sounds unpretty.. If the branches were detected and mapped properly, I dont see what could have gone wrong.. Could you take a look at git side, check the log, and see in the commit messages at the very end of the commit messages, are there stamps like `git-tfs-id: [(tfserver)];C123123`? I hope they are there in the git log. Please check your git branch and the latest commits (those from tfs) and see that info line and check if the changeset number actually match. If they don't, maybe that will be next-to-recent tfs commits. In this case you will be able to pull from tfs and merge easily. – quetzalcoatl Feb 13 '17 at 14:26
  • However, if the [server]Cxxxx lines match perfectly to your most-recent-TFS-commits and the file contents in git does not match the contents in tfs.. then either the import failed (complain to admin who did it), or there is a slight chance that ... you are not the first person to look at this branch. The import might have went fine, and later someone could do a damaging `rebase` or simply `force-push` some trash to the repository.. I find it highly unlikely since it's "your branch". For some time after, the old contents are still recoverable at server side (`reflog`, etc) - admin can see to it – quetzalcoatl Feb 13 '17 at 14:33
  • @quetzalcoatl I don't have the commit in this format because I cleaned the message ( `git filter-branch -f --msg-filter "sed 's/^git-tfs-id:.*$//g'" -- --all`) – J4N Feb 14 '17 at 06:16
  • @quetzalcoatl And we are all working in the same room, and I was pretty clear that nobody should use it before transition was complete. missing commits were from 1-2 years ago, and the history show nobody removing thoses lines. – J4N Feb 14 '17 at 06:17
  • 1
    `I don't have the commit in this format because I cleaned the message` - I So, in fact, there was someone who rewrote the history at least once after the import. Well then.. with some luck you can still find the original history (the unmodified imported state) in `reflog` or in i.e. my favorite `gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )`. I suggest you do it. Then, check out the unmodified state as a detached head or create a temporary branch there, and compare it against TFS. If still different, check the info line and Cxxxx numbers. – quetzalcoatl Feb 14 '17 at 09:25
  • I keep repeating that, because that's the easiest/fastest way to see if it was just a commit skipped, or if it was something worse. If you are unable to find the unmodified history, or if it indicates correct Cxxxx numbers and everything looks fine, then the only thing I can think of is to start over and try importing only that one faulty branch into a new git repository, and see what happens... – quetzalcoatl Feb 14 '17 at 09:29
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/135661/discussion-between-quetzalcoatl-and-j4n). – quetzalcoatl Feb 14 '17 at 09:32

1 Answers1

1

For now, since I've people waiting to work on this, we decided to use the migrated version, to clear the directory and paste the latest version from TFS, then I did a git add ..

At this point, I've everything up to date, and I only partially loose the history of the "corrupted files".

J4N
  • 19,480
  • 39
  • 187
  • 340