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.
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?
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?
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).
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 :)
