Hi Team,
we had some issue in one of the branches in svn and that issue got fixed but now after that fix svn mirror failed in bitbucket, can you please advise ASAP
I have added support zip and UI error snaps
Hello Manjunatha,
could you please describe in a little more detail what was the SVN branch issue you had and how had it been solved?
one of the file in branch-1 got corrupted in the rev 285815 after we are unable to checkout or commit the code into this branch-1 getting this error "svn: E185005: Decompression of svndiff data failed "
in bitbucket svn mirror also failed with attached image(4) error
somehow it got resolved by svn admin team, looks like they removed this rev 285815 from svn
after this fix , we are able to commit and checkout from this branch-1 but svn mirror is still failing
Thank you for the information.
This change seems to be the reason for the issue then, the add-on expects this revision, but it does not exist. The best way to resolve this is to re-build the repository from a earlier revision – say, from the revision 285810. This can be done on the Support tab in the SVN Mirror add-on UI in the affected repository settings:
Rebuild From field and press the Rebuild button. The add-on will reset the repository state to the revision 285810 and then re-import all the latest revisions thus resolving the issue.
Hi,
i started to rebuild from 285810 it is still runnig and the log says below it is started from r285810 and moving backwards , looks like it will update till rev 1 , is that correct process ?
2021-06-23 08:08:23,423 rebuild - Pid file ‘/media/atl/bitbucket/shared/data/subgit/repositories/1123/subgit/daemon.pid’ deleted.
2021-06-23 08:08:23,424 rebuild - Trying to release file lock on ‘/media/atl/bitbucket/shared/data/subgit/repositories/1123/subgit/daemon.lock’.
2021-06-23 08:08:23,424 rebuild - Released file lock on ‘/media/atl/bitbucket/shared/data/subgit/repositories/1123/subgit/daemon.lock’
2021-06-23 08:08:23,425 rebuild - Closed random access file ‘/media/atl/bitbucket/shared/data/subgit/repositories/1123/subgit/daemon.lock’
2021-06-23 08:08:23,434 rebuild - Skip upgrade tasks: daemon binaries located in non-standard directory
2021-06-23 08:08:23,452 rebuild - Executing [chmod, -R, g+rwX, /media/atl/bitbucket/shared/data/subgit/repositories/1123/subgit/tmp]; environmentVariables={};workingDirectory=/home/atlbitbucket
2021-06-23 08:08:23,490 rebuild - svn authentication manager for ‘‘https://svn.corp.zscaler.com/svn/repos/sm’’
2021-06-23 08:08:23,490 rebuild - added user name credentials: svn
2021-06-23 08:08:23,490 rebuild - explicit user name credentials: svn
2021-06-23 08:08:24,103 rebuild - Updating latest fetched revision for svn-remote “svn” to r285810
2021-06-23 08:08:24,865 rebuild - Extracted commit mapping: b7b0506ac158ce7de53aaa1ab7425de7f10c26f9 => r285814 from metadata commit 9520d6ceeb75c0639eb44d4ae64539d4f6279bca
2021-06-23 08:08:25,026 rebuild - Extracted commit mapping: 71f96f37819c29a8b0943547342a455bb130cfc2 => r285812 from metadata commit 0b604fe6f6af12311067f6cb91d5473c17028fc4
2021-06-23 08:08:25,403 rebuild - Extracted commit mapping: d2172d015b73d224472a29ba31f2b94cff35ae8c => r285811 from metadata commit e08bf8235799c566ddf111bec3037bb6931c32b8
2021-06-23 08:08:25,611 rebuild - Extracted commit mapping: aab19bcd680e13c58845f74c00608bfd8182a6f7 => r285808 from metadata commit c978170cc1859d43dedf8fcdcca7e83ec21dbac6
2021-06-23 08:08:25,935 rebuild - Extracted commit mapping: df66ff9756b633c8e23d3427712e06b96dde0b3b => r285807 from metadata commit e0d0e9be0949111c6205d83d9538f035e255ab09
2021-06-23 08:08:26,007 rebuild - Extracted commit mapping: 35c6635eb7341f8b15a1e0513da4a0656247adef => r285805 from metadata commit 686c413ae48a47130bfa05cb4d607c50421f9ce8
2021-06-23 08:08:26,025 rebuild - Extracted commit mapping: 0997c22430920ab10ff7cf84f192e6a72dff6f48 => r285801 from metadata commit d4b1bc0a82320b02914bd1d144ddae4f97fc5ce2
2021-06-23 08:08:26,163 rebuild - Extracted commit mapping: 473f317dbbcb9653fecb9ae890c69a1cd58d35cd => r285800 from metadata commit 6ba4988cfad1393bc3530bd518bfe0c1ae0cda8e
2021-06-23 08:08:26,390 rebuild - Extracted commit mapping: 8976d66ad2776eb74028c53e05eb3c0d44bbc932 => r285799 from metadata commit 42bcc2d867856a0bdc8c964c2597161cf46bccbd
2021-06-23 08:08:26,589 rebuild - Extracted commit mapping: 988e87168e2dc945fb6d333b663b1624a7a89002 => r285795 from metadata commit e9c7797a775fe592ecb6ed4c640fe37c6dd07d9f
2021-06-23 08:08:27,020 rebuild - Extracted commit mapping: fd8b4d40ab8427896af700dc432bee99dca7a5f1 => r285794 from metadata commit 618499bf2c9b580318262582da4a2a4151b198b7
2021-06-23 08:08:27,154 rebuild - Extracted commit mapping: 67763c12d64901755e0687c07d134f9f1d815dbf => r285792 from metadata commit 8f3f751eb2213c44a23db196d3d90bf0f31a7832
2021-06-23 08:08:27,181 rebuild - Extracted commit mapping: 0e4a1f4ad11655a398e187fb8caac02f8feb488a => r285791 from metadata commit
Thanks,
Manju NS
Hi Manjunatha,
the add-on check the repository history preparing the rebuild, but it’s not supposed to rebuild any revisions earlier than one set as the Rebuild From revision.
Hi ,
ok , which means Preparing rebuild… is currently running , after this step rebuild will start from given rev right ?
thanks,
Manju NS
yes, that is how the “Rebuild from revision” feature works.
Now i can see attached error msg from UI , which means still rebuild activity is still running ? or anything went wrong ?
and also attached latest svnmirror log file from support zip
svnmirror.log (6.1 MB)
Hi Manjunatha,
no, the rebuild is not running judging from the logs, it fails instead with the E160004: Corrupt node-revision ‘0-1.0.r285815/22679’ error. It tries to fetch revisions starting from r285810 to latest r286077, but fails on the r285815. So it looks the revision just cannot be gathered from SVN which most probably means that the SVN database or data is broken and it should be resolved in SVN rather that in Bitbucket. Could you please advise how exactly did svn admins removed that revision in SVN? Also, could you please try to checkout that revision on your workstation with a command-line svn client:
svn checkout -r 285815 https://svn.corp.zscaler.com/svn/repos/smi did get the exact info related to fix from svn admin
am able to checkout rev 285815 , check out completed with out any failure
what will happened if i removed the branch from Bitbucket and recreate it ? any concerns ?
Thanks,
Manju NS
Hi Manjunatha,
so do I understand correctly svn admins fixed something in SVN and not everything worked well?
Regarding branch deletion – if you remove a mirrored branch in Bitbucket UI or in a working copy pushing it then to the central repository, then the branch will also be removed in SVN. If it’s re-creted in Bitbucket, it will be created in SVN again, but this would be a new branch, of course. As long as branches are being removed in regular way, it should not raise any concerns.
I don’t want to remove or recreate anything at SVN, if changes happen that will only at bitbucket side, how to do this?
If I go to branches and delete that mirror branch in bitbucket, is that delete at svn side also?
Thanks and Regards,
Manju NS
I’m afraid there is not way to do anything with a mirrored branch only on one side of the mirror, either SVN or Bitbucket side – this is how the mirror works, it mirrors any changes made on one side of the mirror to another. So yes, if you go to Bitbucket and delete a mirrored branch there, it will be deleted in SVN, too.
Then recreation wont works ,
Our branches mapping config is like below
trunk = trunk:refs/heads/tot
branches = branches/release-1:refs/heads/release-1-bb à this is the branch is having a issue
branches = branches/release-1r:refs/heads/release-1r-bb
for now can we stop mirroring that branch(release-1)? Or can we stop mirroring to release-1-bb and create one more branch called with different name in bitbucket ?
Thanks,
Manju NS
Then recreation won’t works
sorry, don’t get this one. If a mirrored branch is in the mapping configuration, then it will be mirrored and thus re-created the opposite side of mirror once it’s created on the other side.
Do I understand correctly that you have the following mapping configuration:
trunk = trunk:refs/heads/tot
branches = branches/release-1r:refs/heads/release-1r-bb
If the branch release-1 is already present on both sides of the mirror (that is, the Git counterpart called release-1r-bb is already present in Bitbucket which, I believe, is true) then stop mirroring this branch would require the repository to be rebuilt from scratch as removing already mirrored branch from the mapping configuration cannot be applied on the fly. Note, that such a rebuild will wholly re-import the repository from the very beginning using the new mapping configuration (with the branch excluded) so that the branch won’t be present in Bitbucket after the rebuild finishes.
Creating another branch named differently is surely possible, both in SVN and in Bitbucket. If the new branch is not in the mapping configuration, then it won’t be mirrored and will only be present where it’s been created.
Yes,
SVN side we call it as `release-1r and same branch is mirrored as release-1r-bb in bitbucket ```
``
How we can resolve this issue now ?
If we modify the branch mapping as like below and rebuild from rev 1 then how it works ? (release-1r this branch is already exist in SVN not in Bitbucket)
trunk = trunk:refs/heads/tot
branches = branches/release-1r:refs/heads/release-1r-bb-latest
in above config am modifying the git branch name from release-1r-bb to release-1r-bb-latest
Thanks,
Manju NS
The rebuild operation resets the repository state to the revision 1 and then re-import the whole repository from SVN to Git using the new mapping configuration. So after the rebuild the Bitbucket repository is in fact brand-new and contains only those branches that are in the mapping configuration. So if you have the following configuration:
trunk = trunk:refs/heads/tot
branches = branches/release-1r:refs/heads/release-1r-bb
and you remove the second line from the configuration and then rebuild the repository, it will contains only the branch called tot after the rebuild.
How we can resolve this issue now ?
Honestly, I don’t understand what issue do you mean? Removing such a branch is not an issue, it’s perfectly possible yet it requires rebuild, but it’s the only correct way to remove already mirrored branch.
Our problem is we are unable to sync or mirror latest code from the branch branch `release-1r to BB because of some some recent issue fix in svn ```
``
If I rebuild from rev 1 with same below branch mapping configuration will work ? because we already rebuild it from rev-285810 but which is not worked so because of 285815 is having a issue ``
``
trunk = trunk:refs/heads/tot
branches = branches/release-1r:refs/heads/release-1r-bb
2nd option for me is modify the branch mapping from above to below and run rebuild from rev 1 will may help ?
trunk = trunk:refs/heads/tot
branches = branches/release-1r:refs/heads/release-1r-bb-latest
Thanks,
Manju NS
Ok, I got the situation now, thank for clarification. From your previous message I had an impression that the SVN admins has resolved the issue with the revision 285815 and that issue was not actual anymore and only branch exclusion question left. Obviously, that was false impression and the r285815 issue is still present.
I must note here that the rebuild from revision 285810 did not finish due to issue with the r285815 which comes from the SVN side – the SVN server actually reports error 400:
400 Bad Request (https://svn.corp.zscaler.com) org.tmatesoft.translator.util.f: svn: E160004: Corrupt node-revision '0-1.0.r285815/22679'
This error comes from SVN indicating that something was done not right with that revision. The best and the most correct way to resolve if it to fix this issue in SVN.
Trying to remove the branch from the mapping and rebuild the whole repository most probably won’t help either: from one hand, if only this branch is changed in that revision, then removing this branch from mapping will eliminate this branch from import. But as far as I see in the logs, the error 400 occurs when the add-on tries to get svn log for that revision, so the error will arise even if the branch is not in the mapping. Again, then best way to resolve is to fix SVN issue.