We have a three server architecture because we are unable to get access to run subgit on our organizations enterprise gitlab instance.
Gitlab EE <-> Subgit Server <-> SVN
The subgit server is hidden from users. They either commit to SVN or to Gitlab EE.
When commits are pushed to Gitlab EE, a pre-receive hook pushes the commit to the Subgit Server first. We’ve been using this setup for about 6 months and it generally works quite well.
In order to keep the Gitlab EE instance master branch up to date, we have a user-post-hook on the Subgit Server, which is only triggered in the svn->git direction by checking SVN_LAST_FETCHED_REVISION.
Sometimes, when a user pushes to Gitlab EE, the whole thing works, except that our user-post-receive hook shows SVN_LAST_FETCHED_REVISION is defined, so it thinks it’s an svn commit and tries to push the commit back to Gitlab EE.
The git client that performs the original push gets an error code and our CI pipeline fails because there is a race to rewrite the master ref e.g.
remote: error: cannot lock ref 'refs/heads/master': is at 630fd1a174e4094318a70d3def527399fa949b6f but expected 1189e52b643da166946bacb7f5b3f225469d87d2
It’s a minor issue because the end result is correct, all 3 repositories are at the correct ref. However, I’d like some help getting to the bottom of the issue as to why SVN_LAST_FETCHED_REVISION is not always a reliable indicator of the sync direction.