The SVN version is ok and, actually, it’s not SVN that is to check, it’s rather SSH server daemon on the SVN server. I would first check the ssh daemon logs to find out what are the errors there. Also, if possible could you please share you setup details so that we could try to re-produce the issue on our side, too?
Thanks Ildar. I’m travelling for the next 3 weeks so I’ll get back to this after that. I’ve informed our team to just restart the daemon in the mean time whenever the issue occurs.
Hi Ildar,
I’m back and I upgraded to 3.3.15 and reran subgit install on the repository. This time I’m getting the following error in the daemon log file.
daemon.0.log (24.9 KB)
Hello Ravi,
as far as I see in logs, the installation was successful, SubGit was able to connect to SVN, read the status and determined that the repositories are in sync, the latest revision in SVN is 50446 and that very revisions is the last imported to Git. So the mirror looks good now.
So I should ignore that error?
I have the local repo syncing with GitHub but someone else did a commit to GitHub and now the post hook fails and says I should integrate the remote changes. Any idea how I should do this?
Hello Ravi,
I don’t see the SSH agent connector exception affects the mirror in any way, so if we are talking about that error, then yes, it can be safely ignored, I suppose.
As for the changes made to the GitHub repository – a commit made to GitHub diverges its history and thus those changes should be integrated to SubGit repository. The changes should be fetched from the GitHub repository and merged, this is described in this article:
TMate SubGit: SubGit for GitHub
Note, that if the changes from GitHub is merged to a mirrored branch in SubGit repository, they’ll also be synchronized to SVN.
Hi Ildar,
Thanks for the link. Unfortunately there was a commit to the SVN repository after the pull into the GitHub repo. So the two have diverged and as the document states “push origin --all --follow-tags” fails. At this moment I haven’t found a way to revert the pull request in GitHub in such a way that the commit version goes back to what it was before the pull. Is there another way to fix this?
Hi Ravi,
indeed, the main issue here is that the history in the SubGit repository and in GitHub diverged and there are different conflicting commits in some branch – and that is why we recommend making GitHub repository read-only in such a setup.
To resolve this issue, the branch history in SubGit and GitHub repositories should be set uniformly. It can be done in different ways depending on circumstances: if, for example, the changes made in GitHub are not to be kept, then the branch can be just force-pushed thus overwriting the remote branch and dropping the changes in GitHub. If the changes are to be kept, then probably the best way would be to checkout them into a separate branch, replace the original branch with one from SubGit and then manually merge the latest changes and then synchronise then back to SubGit and then to SVN.
Ok. So I did a git reset to an earlier commit and then the push worked. So looks like I’m in business. Will now keep a watch on the 100% usage issue.