We were migrating one repository from SVN to Bitbucket but all branches are not coming at Bitbucket side. Codes come under source tab but at Mirror status is still showing as Importing after 4 days. Not sure what is happening?
Is there any limit for Branch number during the migration? There are total 141 SVN branches out of which 87 branches has been migrated
Why message is coming like Importing? Does that means migration hasn’t been completed yet? Attached is the screen shot for the same.
There is no difference in size of repository since 11th of September 2019. Repository size is not increasing in case migration is still going on. Attached is the screen shot for the same.
Attached is the list of SVN and Bitbucket branches. Highlighted in RED is not migrated.
We used below mentioned configuration for this migration:
SVN Repo URL: https://svn.dts.fm.rbsgrp.net/style/style/
We tried this migration twice but results are same. There is no problem of space at the server side. Please let us know how we can migrate all available branches from SVN to Bitbucket
In case you require more information then please let us know.
judging from the status screenshot, the import process has not yet finished and continues. The add-on shows error messages and erroneous status if any problems occur and the import fails, so the “Importing” status means the import is still in progress. The import process can take a long time, it depends on revisions number in the imported project, the repository size, network speed, etc., and 4 days may be a reasonable time for your case, especially taking into account branches count.
As for the branches’ absence – the add-on imports revisions sequentially, one revision after another. The fact the import is still in progress means that not all the revisions have been handled and some branches indeed may not be imported yet, they will be appearing in Bitbucket as correspondent revisions are imported. Ther’s no limitation for branches number, all the branches that are in the mapping configuration will be imported.
It’s hard to tell for sure why the reported repository size doesn’t change in Bitbucket UI as there may be many reasons for that. For example, it may happen if the add-on is busy importing a very big revision all that time – in this case, it doesn’t write the data to the repository until all the data is received from SVN and processed, so if the reported size won’t be changing during this process, indeed.
So, it looks like the add-on is performing import normally, only it takes a long time, supposedly, due to high repository size and/or its long history. It would worth, however, to check logs to find out what is happening there, could it be possible to collect logs on the Support tab (Create ZIP feature)?
Hello.
This error means that the add-on front-end is unable to communicate with the backend, but unfortunately, it’s hard to tell what is the reason for that and it also requires investigation. Another way to collect logs is to gather them right from the server filesystem. Bitbucket server logs and SVN Mirror add-on global logs reside at the following path:
BITBUCKET_HOME/log
Bitbucket logs are named like ‘atlassian-bitbucket.log’ (this is current log file) and 'atlassian-bitbucket-.log (historic logs). The add-on global log called ‘svnmirror.log’ (current) and svnmirror.[1,2,3].log.gz (historic).
Repository-specific SVN Mirror add-on logs can be found at the following path:
@ildarhm: Please find the attached support zip.
We checked the log as well and didn’t find any action after 10th of oct, still status is showing importing.
A possible solution is to upgrade the SVN server to a version that includes the fix for this problem. Another solution is to use URL that points to the repository root, not directly to the project, but this approach would most probably require a rebuild. To apply the latter approach, stop the import by pressing Stop button and then perform uninstallation by the button on the right. After that, change URL from that you had previously set to a URL that would point to the repository root directory; then change the mapping configuration accordingly. So, if the repository root URL is https://svn.dts.fm.rbsgrp.net. then the mapping configuration should be set like this: