SVN Mirror app does not seem to be migrating repo from SVN


My client needs help in migrating SVN repos from Bitbucket. We installed the SVN Mirror for Bitbucket add-on using a trial license and created a repo for mirroring, but it does not appear to be migrating data from SVN. The destination repo came up empty after the synchronization completed.

My client has an urgent need to migrate their SVN repos to Bitbucket and would like to use this product for their migration. So I was wondering if we could set up a screen-sharing call to get the configuration of the Subversion Mirror working correctly.

I’m available on Tuesday and Wednesday from 8:00 AM to 12:00 PM PST.


Hi Romeo,

thank you for reaching out to us on that matter.

I’m afraid, though, that we cannot manage the conference call at this time, so I would rather suggest trying to diagnose the issue here. The most probable reason for such a situation – the initial import finished successfully, but the target Bitbucket repository is empty – is incorrect mapping configuration that does not reflect the SVN project layout correctly and SVN Mirror add-on thus is not able to reach any data. To resolve the issue make sure that the SVN project URL is correct and the relative trunk path is correct (in case of automatic configuration) or all the mapping paths are correct (in case of manual) so that the relative paths point to correct SVN directories. If the issue continues, please share the directory structure of the SVN repository that you are trying to migrate along with the SVN Mirror’s Support Zip (it can be collected on the Support tab in the add-on UI).

Thanks for getting back to me, Ildar. I managed to get the SVN mirroring going, but we found the following issues:

  1. Not all the branches are migrated yet e.g. branch b10_0-8 is still not there (there are lot more)
  2. I can not see commits beyond Oct 7, 2016. Seems like it cannot fetch commits beyond that date.
  3. I saw an error in sync on the UI, please see enclosed snapshot of the synchronization status:

Seems like the synchronization is failing at the same point with the same error (as it was failing with git-svn).

I generated a support zip file, but it generated 2 files. I will send the 2 files shortly after sending this reply.


I’ve uploaded the 2 Support Zip file to cloud sharing service. Here is the link:


Hi Romeo,

  • unfortunately, the logs do not contain the whole history of the translation, the oldest logs start with the current synchronization error, so it’s hard to tell why the branch did not appear in Git if it should have already been imported – an immediate assumption is that it may not be included in the mapping configuration (that is, not reside in the SVN branches directory) so that it’s just not included, can this be the case? Also, the user set in SVN Mirror add-on to access the SVN repository may not have an access to the branch for some reason.
    But on the other hand, the branch may not yet exist in the history – as far as I see in the latest log, the latest fetched revision is 239138, the add-on fails to import the revision 239140, while the latest revision is 342646, so those absent branches may just be created later that r239140, can this be the reason?

  • it’s not completely clear, do you mean that the history in Git starts from a commit made on Oct, 7, 2016 while the SVN history goes beyond this date? Or do you mean that is the latest commit on the Git side at this moment? In the latter case this is expected, the import process has stuck at the revision r239140, so later commits have not just been imported, once the issue with the import is resolved, they will appear in Bitbucket. In the former case, there were probably a branch move/renaming that was made not by SVN means, in that case the add-on is not able to trace history through the move or rename.

  • it looks you are hitting an old SVN bug that leads to this Can't get entries of non-directory error:
    [SVN-4791] FSFS Can't get entries of non-directory - ASF JIRA

    It comes from SVN, so I’m afraid, little that SVN Mirror add-on can do with it, this issue should be resolved on SVN side

@Shiva, attached below is the reply from Ildar (TMate Support) regarding your findings. Please review and feel free to reply to his questions directly as I don’t have admin access to the SVN server and enough information of history of the XDMP repo.

@ildar, could you please add “” to the support ticket so he can reply directly to any of your inquiries going forward?



ildar, I replied to your email using “TMate Support”, but it bounced back. Do you have an email address that we can use to correspond with you directly?


Hello Romeo,

once a user is registered on our support forum, the user is able to see public channels and add messages to them. I don’t see Shiva registered on the forum, so I think, it would be the first required step to register here.

Hi Ildar,

Thanks for working on this case.

It’s a little hard to understand your first point. I am not sure how the mapping configuration is made. Can I fix it somehow?

The userset in the add-on does have all the permissions. Anyways, since the user is able to push up to a revision number to a branch (partially), I expect it won’t be a permission issue if he is not able to push the rest. Why I am saying this is because when I check the pushed branches, they are not the latest i.e. do not have the latest commits from svn, but do have some revisions
Sorry did not understand the branch existence point. Can you please help me understand it better?

Also, If we are hitting an old svn bug (which is fixed now), we are trying to migrate our culprit repository to the latest svn and then we will try to migrate from there. I will update how it goes.


Hi Shiva,

SubGit has a configuration file that allows to adjust different aspects of SubGit behaviour and mirroring operations; among those setting there are a few that consists so-called mapping configuration – that is part of SubGit configuration that describes how to map SVN entities to Git counterparts. If some of the SVN entities (an SVN branch, for example) is not included in the mapping configuration, then it won’t be imported to Git and won’t mirrored and that is what I supposed. But I’d like to emphasise, it’s just an assumption, it may also be absent because the initial import has not finished.
Just in case, we have a comprehensive guide for mapping, find in on the page below:

TMate SubGit: Branches and tags mapping

Hi Ildar,

Our current svn server is running on 1.9.9. I also tried it on 1.10.7 and on both of these servers migration is still failing with the same error. Why we tried on these versions was because we checked the referred svn bug, and seems like that bug is already fixed in these versions. Please correct me if I am wrong.

We are really running out of ideas. Please suggest what can we possibly try to see if we can use SubGit for migrating our code from svn to git


Hi Shiva,

may I ask you have you tried to set the translate.useGlueFetch to false in the affected repository?

    useGlueFetch = false

If not, could you please try to add this setting in the mapping configuration?
If it is still failing please collect new for the affected repository, and, additionally, please collect the svn logoutput for the affected revisions:

svn log -v -r 239120:239150 <SVN_URL>

Hi iLdar,

Romeo did tried putting useGlueFetch = false in the setting today and tried mirroring, but it failed at the start with this error:
The default branch is set to "refs/heads/master" but does not exist. Configure the default branch in the repository settings.

He will be attaching the soon.

I will only be able to convince my manager to buy this tool if we are able to mirror the affected repository, so its very important for us to resolve this issue

Wondering, if you can be available for a short call on Tuesday (12/21/2021) 7:00 AM Pacific Timezone to discuss this issue? Probably it would be easier to explain the problem over a video call.


Hello Shiva,

this The default branch… does not exist message is being raised by Bitbucket itself, not by SVN Mirror add-on. This message means that there is no default branch in the repository, but it should be possible to switch to any other branch (or even set some branch to be default) if there are any branches in the repository. The master branch absence, in its turn, may mean that the initial import has not yet been finished and the master branch has not yet been created or it may mean the mapping configuration is not correct and the branch has not been created just because there is no counterpart SVN directory. In any case, the should reveal what is going on in the repository; or, otherwise, you can check in Bitbucket UI switching to another branch and checking if the recent SVN revisions have been imported already.

Hi ildar,

Here’s the link to the support zip files generated today.

I think Shiva’s request to do a screen-sharing call next Tuesday is a good call. It should help speed up the ongoing troubleshooting. Please let us know if you or a member of your team can meet with us next Tuesday.

Romeo Cavestany

Hello Romeo,

I’m afraid we are not able to participate such a call.
Judging from the logs, the initial import has been started again from the very beginning and the revision r57025 was being translating at the time of logs collecting. Since the initial import is still ongoing the The default branch… does not exist error is normal and expected, it does not indicate any problems and will disappear after the initial import finishes.

Hello Romeo, Shiva

could you please advise has the situation changed since the latest log collection? Have any errors appeared during the initial import (is any error shown in the add-on UI in the repository, especially that Can't get entries of non-directoryerror?) or has the initial import finished successfully?