SVN_LAST_FETCHED_REVISION is sometimes wrong

#1

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.

Thanks!

#2

Hello Jonah,

it looks to be some error, indeed, and would require an investigation to find out the cause. May I ask you to provide us with SubGit logs that would contain an example of the issue? That would help us a lot to find out the cause.

#3

Hello Jonah,

in addition to SubGit log, could you please check does this situation happens when there is a new SVN revision committed just before the GitLab push?

#4

Hi Ildar,

it turns out this latest one is something that looks similar but may not have been the same issue. I need to do some more work on my end for this case. Gitlab all by itself can be a bit flaky. However, here is one of the older examples for the issue I described above:

In the logs for my user-post-receive-hook:

2020-08-18 15:15:21: syncing svn revision 922062
To https://url.git
    9014fbd50..a8e1c6bd2  master -> master

Generated from user-post-receive code that looks like this:

if [ -n "$SVN_LAST_FETCHED_REVISION" ]; then
    echo "$currentDate: syncing svn revision $SVN_LAST_FETCHED_REVISION"
    ...
else
    echo "$currentDate: skipping git commit sync: $(git rev-parse refs/heads/master)"
    ...
fi

When I check 922062 in the svn logs:

------------------------------------------------------------------------
r922062 | <name> | 2020-08-18 11:14:19 -0400 (Tue, 18 Aug 2020) | 9 lines

<msg>
Git: <user>
a8e1c6bd247fc31f6202992cef4af7c9a0e0c6b0@mainline

It contains the subgit-generated part of the commit message. i.e. our subgit config says:

svnCommitMessage = %message\\nGit: %author\\n%commit@%branch

Since the examples are older I only have the subgit pre-receive-hook.0.log, the others appear to get flushed. It appears to succeed and subgit is showing the sync in the git->svn direction:

[2020-08-18 15:14:21.376][pre-receive] Received '(message (29:  a8e1c6b => r922062 mainline ))'.
[2020-08-18 15:14:21.376][pre-receive] Received '(message (27:Sync completed successfully ))'.

yet somehow the user-post-receive hook is going down the svn->git path.