We are trying to do rehearsal for upgrading bitbucket server from 5.7 to the latest 6.3 and after upgrade, we found that the SVN mirror page under repository is throwing exception. See the following error and the attached screenshot.
Can you advise how can we fix this problem ?
regards,
Terry
Retrieving mirror data from Bitbucket Server
Establishing background long poll connection (will try for 10 seconds)…
we are now maintaining two separate versions of SVN Mirror add-on – v.4 for Bitbucket 6 and v.3.4.x for Bitbucket 4/5:
Functionality is the same, they only differ in Bitbucket-specific code. I’d recommend updating the add-on to the latest version 4.0.3 after Bitbucket is updated to 6.3; after that, there should be no errors.
I did the bitbucket server upgrade during the last weekend. I encounter a few issues after the upgrade:
There are a few repository with out of sync warning and there is a button for rebuild it. I click rebuild as this is the only option and after a few hours, they resumed to normal state. Can you advise why there is such out of sync warning ? (I remember this occurs only on 4 repositories)
There are some stopped SVN mirror repositories. When I visit those stopped repository, it will prompt for incompatible meta data and ask me to upgrade the meta data. Do we really need to update the meta data for this “stopped” repository ?
The upgrade process doesn’t suppose any repositories to go out of sync. My assumption is that it might appear during the metadata upgrade but it is a relatively fast operation that should finish with no other actions. As for the stopped repositories – actually, metadata should have been updated during the add-on upgrade, too, as in active repositories, so it’s not completely clear why it does complain about incompatible metadata and requires some investigation, as well as the ‘out of sync’ issue.
Could it be possible to provide us with a screenshot of the ‘incompatible metadata’ message and add-on logs from that repository? Also, please collect logs from one of the ‘out of sync’ repositories.
Logs can be collected in the add-on UI: Repository settings - SVN Mirror - Support tab - Create ZIP.
OK. In fact, I found four repositories out of sync and need to trigger a rebuild on each of them. Attached is the support zip (one of the out of sync repository is called RmpSpTranscodePack).
Also, we have some build failure regarding those “stopped” repository where meta data upgrade is needed. Seems like both git tag will trigger this process (or visiting the SVN mirror page will trigger this). See the attached screenshot. I suppose all of these meta data upgrade should be DONE for all repositories.
the metadata in repositories should be updated automatically during the upgrade process, yet if there are many repositories then it can take some time and repositories may be waiting in a queue. This “metadata upgrade is pending” should appear when a repository is awaiting upgrade in a queue and it should be processed when its turn comes. It is safe to start it manually pressing the 'Upgrade" button.
As for the “out of sync” repository – its metadata has been upgraded and the mirror verification started. The add-on detected some inconsistencies during the verification and that was the reason why the repository was marked “out of sync”. The rebuild did resolve the issue, so the repository is ok now, only one thing is not completely clear – was the mirror in this repository set to use r180000 as a minimal revision from the very beginning or the minimal revision was set prior to the last rebuild?
The mirror in this repository was set to use r180000 as a minimal revision from the very beginning.
Any idea why there are such inconsistencies ?
Also, the metadata upgrade didn’t trigger at all for all the “stopped” sync repositories (as I have to go through all our repository to make sure those meta data are upgraded). From my observation, meta data upgrade is triggered when there is git push or when user goes to the svn mirror setting page (and it will trigger automatically, no need to push the upgrade button).
according to the logs, verify feature found an issue in a revision near 35000. If the r180000 was set as minimal revision, then this verification outcome appears to be erroneous, we are checking the code to find out why this revision was taken into consideration while r180K was set minimal, I’ll be keeping you informed about results. The repository, though, seems to be in a good state, no issues should have been introduced by this verification issue.
judging from the screenshots, authors mapping changed since last translating and because of that Git names changed during the rebuild. Git author name is a part of a commit and if the name is changed, the commit hash is changed, that’s why commits hashes are different.
Tags, however, shouldn’t be affected – if they were synchronized with SVN, the add-on should re-create them during the rebuild. Could you advise please are all those tags present in SVN or those were Git-only tags?
Hi Ildar Khusainov,
I would like to ask why git author name changed ? I suppose they are the same and no one change commit author name.
Those tags are git only tag (I suppose they will not sync to svn side).
I cannot say for sure, but judging from the screenshot it looks like authors mapping has been changed. For example, NG-29833 was made by Alvin Li before the rebuild, but after the rebuild it’s authored by ‘ali’ which looks more SVN name translated without author mapping. So my assumption is that the repository-specific or global authors mappings were changed and that led to the changes to authors names.
As for the tags – rebuild indeed does remove Git-only tags as during the rebuild it reset the repository state to certain revisions and then re-translate the data from SVN.
Hi Ildar Khusainov,
In fact, Alvin Li = ali. I don’t change authors mapping at all but just click the Rebuild button. Do you know why this changed the author name ?
As for the tags – rebuild indeed does remove Git-only tags as during the rebuild it reset the repository state to certain revisions and then re-translate the data from SVN
This is not good as we lost the git tags. How can we prevent this from happening again ?
I can’t say for sure at this point, a deeper investigation is required for that. May we have the authors mapping from this repository and global authors mapping for the investigation?
As for the Git-only tags – we are doing deeper investigation on that part, I’ll be keeping you informed.