Migration still in process after a month

SVN Mirror
#1

There is need to migrate one SVN parent repository. But even after a month, the status still shows ‘IMPORTING’.
Parent SVN Repo path: https://svn.dts.fm.rbsgrp.net/ice (Attached is the screenshot - SVNParentRepo)

We have used below mapping
Subversion Project URL- https://svn.dts.fm.rbsgrp.net/ice

trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*
shelves = shelves/*:refs/shelves/*
#2

Hello,

we would need more information to investigate it, could you please collect logs from the repository? The logs can be collected on the Support tab in the add-on UI in the repository (Create ZIP feature).

#3

Hi,

Please find the attached logs and let us know if anything else is required.

Thanks.

#4

Thank you for the logs.
There’s only yesterday’s and today’s (January 5th and 6th) information, however, but judging from it, the add-on is indeed still translating the repository, the logs only reflect the normal translating process. At the time of logs collecting it was translating the tag called ICE and it looks that add-on only managed to translate about 4,33 GB of data over the period from Jan 5 12:41 till Jan 6 06:16 which seems to be relatively little for that period. I assume that the network transmitting speed is low as there are no signs of overload or other issues, but data receiving speed is about 70 kilobytes per second which is slow and that may be the reason why the import is lasting so long.

#5

Hi,

Would there be any reason for this specific migration being so slow?
We have been performing other migrations but that did not take so long.
Also, is there a way we can speed up the migration process for this repository?

Thanks.

#6

Attaching the logs that i tried to generate again. I get connection failure while generating these logs , so it is not generating all the logs.

#7

Thank you for the logs.
They contain not that much new information, however, pretty much the further process of the translation. From the logs, it doesn’t look like the Bitbucket server is overloaded, so my assumption is that this cause comes from the SVN side or from the network. This repository appears to be very big, it probably much bigger than other repositories that were translated before, couldn’t this be the reason for the translation time difference between this repository and others? Also, 70 KBps is notably low speed, couldn’t there by any networking issues? Or could it be disk speed issues, either on SVN or on the Bitbucket server?
By the way, there’s also one more thing: you’re using the standard layout for the translation and if there were erroneous branches in the repository history (for example, created not by copying ‘trunk’, but by copying the root directory of the repository), then these branches may significantly increase repository size for translation. We usually recommend using auto-generation of the mapping configuration to avoid such issues; but it’s only about the repository size, it doesn’t explain the speed of translation.

#8

Hi,

We are facing similar issue with one more repository where the speed of translation is really slow. However, the translation works fine with many others. The source and the destination servers remain same in all cases. Please let us know how we can fix this.
Mostly, we are facing issues where the migration is happening at parent level.
For example: https://svn.dts.fm.rbsgrp.net/ice , https://svn.dts.fm.rbsgrp.net/sigmarepo/

#9

Hi,

these repositories appear to be private, they are not accessible over the Internet, so, unfortunately, we cannot check the repositories over the links you have sent.
Regarding the repositories translation speed – the repositories may reside on the same server, but they can differ from each other nonetheless, and those differences may cause noticeable differences in the translation process. For example, one repository can reside on a fast disk device and other on a slow one, and that can cause significant difference in speed. Or, as I mentioned before, one repository may have a clear and straight history while another can have some issues, like copying the root directory as a branch. Such things in SVN history cause a significant increase in data size during the translation that can cause low translation speed, too.

So, the speed of translation may differ significantly even for repositories on the same server, and there is no single universal solution for that, every such a case requires investigation to find out what is the reason for slow translation. We would need logs from the affected repository, ‘svn log -v’ output for the correspondent SVN project or repository and, advisably, logs of the initial translation from another repository (the one not affected by the issue).