ian.fischer.winreality

When attempting to export our Plastic SCM repo into a Git repo we tried cm fast-export: Here is the batch script we are using: @echo off set "EXPORT_FILE_NAME=D:\WINS.fe.05" set "MARKS_FILE_NAME=D:\marks.05.cm" del %EXPORT_FILE_NAME% del %MARKS_FILE_NAME% cm fast-export WINS_Clone@local %EXPORT_FILE_NAME% --export-marks=%MARKS_FILE_NAME% And then we open a bash window and attempt to import it into a new Git repo #!/usr/bin/env bash EXPORT_FILE_NAME="/d/WINS.fe.05" MARKS_FILE_NAME="/d/marks.05.cm" GIT_REPO_DIR="/d/Repos/WINS5.git" rm -R -f "${GIT_REPO_DIR}" mkdir "${GIT_REPO_DIR}" pushd "${GIT_REPO_DIR}" git init --bare . cat "${EXPORT_FILE_NAME}" | git fast-import --stats --import-marks="${MARKS_FILE_NAME}" popd When we run this we get the following output: Initialized empty Git repository in D:/Repos/WINS5.git/ fatal: corrupt mark line: 2 20939 fast-import: dumping crash report to fast_import_crash_28364 ~/Desktop The crash report is relatively small so I will just include it in this post: fast-import crash report: fast-import process: 28364 parent process : 1 at 2023-02-08 19:22:12 +0000 fatal: corrupt mark line: 2 20939 Most Recent Commands Before Crash --------------------------------- Active Branch LRU ----------------- active_branches = 0 cur, 5 max pos clock name ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Inactive Branches ----------------- Marks ----- ------------------- END OF CRASH REPORT Looking into the code behind fast-import where it attempts to load the marks it seems it expects a ':' in the beginning of the line: https://chromium.googlesource.com/external/msysgit/git/+/fb6aa9a54fa455d8e8b9e3971b1738afabab2679/fast-import.c What is the cause of this?

We did try letting the operation run. It turned out it took 4.16 hours in "Exporting...", 1 day and 6.83 hours in "Packaging..." until it started to do the "Uploading..." and then got a stdin send error. - 41086 changesets to push Receiving references... OK There are changes to push. Exporting... OK Packaging...... OK remote: g...... | 17.44 GB/152.98 GB remote: ======================================================================== remote: remote: stdin send error: EOF remote: remote: ======================================================================== remote: Uploading...... | 17.44 GB/152.98 GB From that point we have left it running for 2 days and 8 hours but it has not changed anymore. Enforcement of code review pass by a specific number of specific people/groups before allowing merges into a branch. Better code differences when viewing code reviews. Better notifications when code reviews are added. At this point, what is your advice after it has not finished uploading after 2+ days and that stdin error?

I can leave it running, but after 17+ hours when would you expect to see some progress before giving up? We want to checkout and use the Git code review tools. Would you have different advice if we were planning to fully move to Git vs. utilizing both systems? Yes, our primary account email is subscriptions@winreality.com. We are unsure. The front end and asset teams know and are fine with Plastic. The backend and code developers want a better code review process and are looking into ways to use other tools.

We have been trying to use GitSync to work and it will not finish after many attempts with fast-export that kept failing. We have a very large repository at some 400+ GB, and each time we get to the "Packaging... 0/576226" it just sits there and does not continue without error even after letting it run for a 12+ hours it remains at 0/576226 progress. Because Git cloud providers do not have plans for repositories that are larger than 400 GB, we planned to first perform the export into a local Git repository, then prune history items, mark items for LFS, and find an external LFS hosting location like AWS to get our repository to an acceptable size. We tried first using Git daemon to expose a Git URL for GitSync to push to git daemon --base-path=. --export-all --reuseaddr --informative-errors --verbose --enable=receive-pack It would then take about 4-5 hours performing the "Exporting..." stage and then get to Packaging and not do anything else. Looking at the logs in %LOCALAPPDATA%\plastic4\logs\cm.log.txt at the end of the Plastic GitSync "Exporting..." phase it finishes registering all the branches to push, and then the tags, and then it says it purges connection to local (which I am assuming it means it is disconnecting from the local Plastic repo to then send the packed results to the Git repo but not for sure). It then just logs info about it's "BUFFER POOL CONFIG" every 30 minutes for over 12+ hours. We contacted support who told us that Git daemon was not as performant as a full Git server and that what was going wrong. We then setup a local hosted GitLab server on a Linux machine with full ssh support. We experimented with smaller Plastic SCM repositories and they all completed without any issues and we were able to view them in the private hosted GitLab browser and all the appropriate history. When attempting to now do the GitSync to this full Git server the same issue occurred. It still took the same 4-5 hours in it's "Exporting..." phase but hung at 0/576226 progress in the "Packing..." phase and could never get to the "Sending..." phase at all. Is there any known reasons why Plastic will not make progress during the "Packaging..." phase? What are some alternative solutions that might be better to export our Plastic SCM repo to a Git repo?