Twin17

So, the duplicated heads were merged into one (see screen) But it seems still to be bugging out, it still points to those branches as double-headed

I will have a look if any of the two is applicable. Actually the bulk delete left few duplicated heads, should be around 15, so it would be doable to merge them back. We'll see! Thanks for the extensive support for now!

Sadly backups we have now are quite old, the project is still undergoing development, and as of now we would lose weeks of work. That would be also when resyncing the git one. Would keep it like this, if only it wasn't that when attempting a new sync it gives multiple merge error, the manual fix would be *impossible* or just very hard to achieve?

@calbzam Sorry to be here again. So here's what we've done in to solve the problem, but it's still not completely solved. We identified ALL the duplicated changesets and ran a script which iterated through the list to remove them. Still some are stuck and cannot be removed as they have children, and obviously said, the children are other bugged out changesets. (Example Below) Whenever we try to remove one of those it will give the following: Where can we go from here? Thanks in advance

No, we have run the sync from two clients, i have noticed after that this creates this kind of error, and we're working on a solution, which mostly worked but there are some stuck duplicates that cannot be deleted.

@calbzam Sorry for bringing up this post again. It seems there is another issue with the sync. So after the sync was done, we waited a bit, some commits and then synced again and this happened: - The sync fails with "/main [other 98 branches], have more than one head. Please merge them to be able to continue synchronizing" - In the branch explorer commits are doubled (see screen below) Any clue as of why this may happen?

Probably yes, it would be a BitBucket UI only issue. I guess i would have to contact their support to let them know. At least this migration works now! Thanks for all the support!

Yup, Steps were the usual, the same cm sync i stated in the OP. Edit: Actually there are a lot of tags in the repo, so my guess was wrong, but at this point, what's the empty tags folder for? The same tags are also present on git, they were synced successfully.

Hi Carlos, After some more analyzing, and also thanks to the tests you let me do, i found the culprit of the error. I update here because it could be useful also for other people in the future. The last conclusion comes after my tests with current mainline version so: 11.0.16.6994 Also Bitbucket version: 7.20.0 Basically the original PlasticSCM repository didn't contain any tags, so what happened was that the sync process created an empty "tags" folder in the .git data, for the repo. In this case, cloning the repo via Sourcetree did work, but the webUI (which is used for most collaboration tools) was giving a 500 Error. After removing that folder, modifying a random file to let it actually commit and push, makes everything work good again. @calbzam Is this something fixable/patchable? My first stupid idea would be to add a "gitsync" tag with the migration, if the repo has no tags.

I also had a look at the logs, and yes can confirm. Sorry to say but probably it wouldn't be possible to upload the repo to GitHub, it's still private data. Database in the folder rep_xxx is 1.12GB, so nothing too crazy big. If it's useful for you i can package and send that to you too. Thanks!

Oh, sorry there was the misunderstanding on my side. Will run with plastic logs enabled and send you the logs, thanks for the pointer for the docs. Anyway, the repo doesn't contain single files bigger than 400MB and LFS is active, so that shouldn't be too much of an issue. I will ask the dev responsible for the repo if we can make the github test. Thanks!

Hi, update! The output after the update changed in this Receiving references... - - 0 changesets to pull - 26918 changesets to push Receiving references... OK There are changes to push. Exporting... OK Packaging...... OK Error: The response ended prematurely. I forwarded privately the debug logs to you @calbzam. Thanks

Thanks for the reply Carlos, I'll try with the steps provided, it takes a while to run, but yes with updating at least the error message is not appearing. Will update back with any results, and if needed I'll forward you the debug logs (the ones from Bitbucket, right?) Cheers!

Hi all, I'm trying to sync / migrate a huge repo which was never migrated before to a private BitBucket instance, but the output gives out an error which is shown below ACTIVE... | - 0 changesets to pull - 26738 changesets to push ACTIVE... OK There are changes to push. The new item cannot be loaded in the workspace. Probably, the path is already used. Please unload the item (from the configuration view) and retry the operation.... OK Keep source changes (preserve the add and discard the move)... OK Error: Unable to read data from the transport connection: The connection was closed.B Steps taken to do the sync: - cm sync <refspec> git <repo> --user=user --pwd=password - cm sync <refspec> git <repo> --user=user --pwd=password --skipgitlfs - On GUI: Select Branch > Right Click > Pull > Sync with Git Debugging steps i've tried: - Remaking the destination repo from scratch (also changing it) - Tracing the cm and git process (nothing unusual) - Checking the debug logs on bitbucket (see below) - Add the plasticpipeprotocol.conf file with various configurations - Test the process a whole lot of times Meaningful Observations: - The files are actually packed and sent to the BitBucket server, as after recreating the repo and "failing" the process once, it shows the exact size of the repo on disk (and in the "DiskSize Calculator" in Bitbucket): 1,5GB ca. - The error below is repeated like a billion times in the debug log, all corresponding to the exact moment when the "upload" should be finalized error: Could not read 814070262e265e90dd2cdb9ea3d82146e0de2cf7 fatal: Failed to traverse parents of commit 987b65accfa419b454a73e23ff84bc8709f7c984 - Error happens both in UI and CLI Can someone help me or at least point me to other debugging steps i could do, or some workaround too! Thanks!

Hello, Sadly i guess not, the error is randomly happening, and as you could see, logs are not very speaking. It's still good to know that this can happen in these known situations, i can eventually warn the devs about it. For now, i don't think we can go much more than this. I'll update in case i get any reproducibility. Thanks!

Hi, I don't think it will help much having the log, as it just does it at the beginning, it's a few added lines over what i already pasted. However i'll attach a log (with changed names) for reference. In the meantime thanks for your help, if you need anything specific to see or if I may help you further, just let me know. tclog.log

Hi, Sorry for the delay, i was asking the developers if they had done any of those actions. They reported back that they haven't renamed or removed CSs, and also one of the usual repos that gives out this error, has not received modifications for months.

Hi all, I have a problem with the TeamCity plugin for Plastic. Cannot find the reason why, randomly, it starts trying to diff the cs:0 of a repo with its parent. A log for broader understanding: Failed to collect changes, error: Error collecting changes for VCS repository '"Project.Vcs.6" {instance id=21304, parent internal id=1753, parent id=Project_ProjectVcs6, description: "PlasticSCM: br:/main@Project.subproject@ssl://plasticserver.com:8088"}' Error getting diff info of 0: Can't diff cset cs:0@rep:Project.subproject@repserver:ssl://plasticserver.com:8088 because it doesn't have a parent. , VCS root: "Project.Vcs.6" {instance id=21304, parent internal id=1753, parent id=Project_ProjectVcs6, description: "PlasticSCM: br:/main@Project.subproject@ssl://plasticserver.com:8088"} In the end the only solution is to recreate the VCS root, and it starts working for a while. Can someone point me in the right direction? Thanks