Hello, this is a query for more information.
We utilize the SVN Mirror app for a few repos that have a bidirectional mirror. Some work happens in SVN, some happens in Git. Two of these Bitbucket Repos are synchronized to a common SVN server. I’ve tried to include some details below.
Bitbucket Repo 1:
Connection details
https://svn/dir1/dir2/trunk
Branch mapping
[svn]
trunk = dir3:refs/heads/master
excludePath = /dir4/dir5
Bitbucket Repo 2:
Connection details
https://svn/dir1/dir2/trunk/dir3/dir4/dir5
Branch mapping
[svn]
trunk = :refs/heads/master
We see a lot of complaints from users that they can’t push, or commit. We believe this is because they are busy repo, have multiple mirrors to single SVN server, so if they repo is busy syncing, they need to wait.
Can you validate this? Can you let us know how SVN locking happens, does that matter? What we can do to minimize timeouts or delays? Is two Mirrors on One SVN server bad?
Sorry for complicated ask.
Hi Steve,
basically, it’s OK to have more than one mirror on the same SVN server, I would say it’s a common setup when several repositories on the same SVN server are being mirrored to Git projects on the same Bitbucket server. The fact those two repositories are on the same SVN server should not cause any issue – unless, of course, it’s a very small server with limited resources, but hardly it’s the case here, right?
What usually cause issues is concurrent change: if, for example, somebody pushes a big change that takes some time to translate to Git, then subsequent pushes will be declined until the very first one is translated and the transaction is fixed. Also, it may happen that somebody pushes changes that conflict with the actual repository content – for example, if somebody pulled master from Git, made their changes and pushed it back, but another developer committed changes on SVN side and in this case the push will stop with a conflict as SVN Mirror first synchronise SVN and Git importing changes from SVN and only after that tries to apply new changes came to Git.
In this particular case some more conflicts are also possible because of the overlapping mappings in the mirrors you have: SVN Mirror add-on does not use svn:lock to lock paths in a repository since that requires additional translation and may lead to issues; but instead, the add-on sends a command to remove special not existing branch-level property subgit:lock within the same transaction which creates an SVN revision during Git-to-SVN translation. This not existing property removal has no effect on the revision itself, but if there’s another transaction that changes the same branch, then either of the two transactions will fail with the out-of-date error, and that is where a conflict may happen: if a new change came to one repository, the property removing may affect the other.
It’s hard to tell for sure what would be the best way to resolve those timeout since it’s not clear what is the main cause, so as a first step I would suggest collecting the errors developers are getting trying to push to Bitbucket or commit to SVN. If that reveals that developers mainly wait until a previous push is translated to SVN, then a possible response could be reducing such pushes size – for example, not pushing several commits at once in a single push; and it would also make sense to consider giving servers more resources to speed up the data translation.
Hope this will help.