Licence Error: EAP: false; types: [NO_LICENSE, CORRUPTED_LICENSE_DATA,

Hey there. We use SubGit to copy SVN Repos to our Gitlab Server.
The Licence we have is Valid until 2023-03-17.

The problem is the repos dont sync anymore! The Log files say following:

Git committers: 0; Git committers limit: 25
License violations: none

What can i do to check my licence? There are around 60 SVN Repos that need to be mirrored to Gitlab.

When i use “register --key …” it says following:

root@cloud:~# /opt/subgit-3.3.11/bin/subgit register --key /root/subgit_key/subgit.key /data/git-data/repositories/@hashed/e9/77/e97776493f213d50b346f81e3f93a78aad1fd0f19c051a38bd8f88b43e46e5b55
root@cloud:~# /opt/subgit-3.3.11/bin/subgit register --key /root/subgit_key/subgit.key /data/git-data/repositories/@hashed/e9/77/e97776493f213d50b346f81e3f93a78aad1fd0f19c051a38bd8f88b43e46e5b5
SubGit version 3.3.11 (‘Bobique’) build #4408

Detecting committers in 19 repositories…

Registration information:

Registered for:      Etienne Frei
Purchase ID:          CM-827615981583402
Git Committers Limit: 25
Free upgrades until:  März 17, 2023


Thank you for registering SubGit!
Visit in case you have any questions and for more information on SubGit.

according to the output you cite:

there’s no license violation from your side. The list written in capital letters like NO_LICENSE, …, etc is just the list of checks SubGit performs to detect whether there’s a license violation; and according to the output you provide, everything is fine.

If the repos don’t synchronize, maybe there’s another [technical] reason for that not related to license. Could you attach the logs (mostly we’re interested in the daemon.0.log) from GIT_REPO/subgit/logs/ directory? We’ll try to find out why the problem happens.

daemon.0.log (811.4 KB)

Here you go, thanks for looking at it!

Thanks for the log. It looks perfectly fine. As you can see, there’re lines like

[2023-01-24 15:16:53.554][daemon][17] Revisions: <fetched=227; last=227>
[2023-01-24 15:16:53.583][daemon][17] Repository fetch completed, fetch took 53 ms.

They appears approximately once a minute. This is because by default svn.fetchInterval is 60 seconds.

So once a minute, SubGit checks the latest translated (‘fetched’) revision and compares it with the latest available revision in the SVN repository. As it finds out they are both the same (227), SubGit concludes there’s nothing to do as both Git and SVN repositories are already in sync.

If one created a new revision in the SVN repository, it would translate that revision in one of those periodic checks. If one pushed to the Git repository, ‘pre-receive’ hook would be executed triggering synchronization as well.

So the current situation of that SubGit installation is perfectly fine, SVN is in sync with Git and thus the daemon is idle.

Or is there a particular issue with the synchronization? E.g. some Git commit is not translated to SVN or vice versa?

1 Like

There seems to be a problem with synchronisation. I just commited a test word file to the SVN Repo and it is now revision 228. I checked the Subgit logfile which says “fetched-228” so it should be correct. but the file simply doesnt show up on the gitlab projekt… is there anything i can do?

I tried this on an existing repo and it didnt sync. I deleted it from gitlab und created a new repo on gitlab and tried again and now it does sync with svn. seems i need to delete all the repos now on gitlab and start over… i just dont know why they stopped syncing in the first place?

Hello Samuel,

judging from the screenshot you’ve shared, SubGit did synchronized the repositories and did importer the newest r228, that’s why now it states

Revisions: <fetched=228; last=228>

The log part on the screenshot does not contain the actual synchronization log, however, it’s just a regular later fetch, so it’s hard to tell for sure why the file does not appear in Git, but most probably it happens due to mapping configuration that somehow excludes that particular file or that particular branch from the synchronization. I’m pretty sure it is not needed to remove and re-create the mirrors to get file to GitLab, most probably the repositories configuration are to be adjusted, but we would need more details about the issue to investigate, namely, repositories’ SubGit configurations, logs, and details about what files and revisions are affected (or SVN logs with those details).

Thank you very much for the reply!

I setup the new repos exact same way as they were befor and now they are working. I dont know why they stopped in the first place but you can view this ticket as solved :)