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.
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).
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:
@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 “shiva.verma@marklogic.com” to the support ticket so he can reply directly to any of your inquiries going forward?
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.
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.
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:
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
may I ask you have you tried to set the translate.useGlueFetch to false in the affected repository?
[translate]
useGlueFetch = false
If not, could you please try to add this setting in the mapping configuration?
If it is still failing please collect new support.zip for the affected repository, and, additionally, please collect the svn logoutput for the affected revisions:
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 support.zip 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.
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 support.zip 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.
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.
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.
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?
