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.
Svn side already fixed this issue ,now we are able to checkout and commit the things into svn but looks like they removed entire revision of 285815 from svn but as per old history in bitbucket svn mirror is not able to synch
Thanks,
Manju NS
Manjunatha, the matter is that the SVN issue has not been resolved completely – the add-on tries to get information about the revision from SVN but SVN fails to provide that information (which it must be able to provide) and reports the error 400 instead. Little that the add-on can do with that – again, just because the error comes from SVN in response to a regular operation – the error should be resolved in SVN instead.
i have excluded that corrupter branch and rebuild from rev 1 , that branch got removed from the list bit still faing with below error
and also it say’s un-synced commits , please find below error
6.1_do_not_branch this is the branch which is having corrupted things and i have removed from mirror now
can you please advise what i need to do for start working our mirror , we don’t want to mirror that corrupted branch anymore
Hello Manjunatha.
The problem is in SVN with the revision 285815. The add-on is not able to get that revision out from SVN. That error occurs in SVN and add-on can do nothing with it, it should be resolved in SVN.
Hi ,
Thanks for the support , we have fixed the issue in svn and all looks fine now
I have one more question now
We have mirrored multiple branches in Bitbucket and we wanted to stop mirroring some branches , how to do that ?
Our current branch mapping is like below
trunk = trunk:refs/heads/master
branches = branches/branch-1:refs/heads/branch-1
branches = branches/branch-2:refs/heads/branch-2
branches = branches/branch-3:refs/heads/ branch-3
I wanted to stop mirroring only branch-3 , can you please advise how to do that ?
Thanks,
Manju NS
Hello Manjunatha,
the straight and the most correct way to stop mirroring the branch is to exclude it from the mapping configuration. If you need the branch to stay in the repository, then it would worth first to make a copy of that branch under another name or in other Git namespace, and then remove the following line
branches = branches/branch-3:refs/heads/branch-3
from the mapping configuration. Note, however, that removing already mirrored branch from the mapping configuration requires repository rebuild, it cannot be applied on the fly.
There is also another way to stop mirroring the branch for your case, but I must warn you that this is not an intended way, but rather a “hacking” way. It will stop mirroring the branch, but it only applicable if the branch will never be added to the mirror again, otherwise it will break the mirror.
So, to stop mirroring the branch-3 on the “hacking” way remove the mapping line
branches = branches/branch-3:refs/heads/branch-3
in three places:
- first, remove it from the mapping configuration in the running config file
BITBUCKET_HOME/shared/data/subgit/repositories/<REPOSITORY NUMBER>/subgit/.run/config - then remove it from the configured mapping file
BITBUCKET_HOME/shared/data/subgit/repositories/<REPOSITORY NUMBER>/subgit/config - finally, remove it from the configuration in the SVN Mirror add-on user interface in the repository settings and press
Apply changes. It should apply it immediately.
After that the branch will still be present both in SVN and Bitbucket, but it won’t be mirrored, so any commit to that branch will only be present on the side (SVN or Git) where it’s been made. I’d like to warn you once again, however, that this way is only applicable if the branch will never be mirrored again. If it cannot be guaranteed, better to stick with the former approach.