Hi,
I’ve been running subgit for quite a while and have a few old repositories running on version 2.0.3. Now I am planning to move to a gitlab integrated recent subgit and the most important repository at least doesn’t import / verify properly. Some other repository worked.
What I’ve done is imported the git repository using gitlab-rake gitlab:import:repos, then I’ve copied over the directories subgit and svn to the new repository, edited the config to adjust the hooks section for gitlab, ran subgit register with a new key and then subgit uninstall followed by subgit install. That worked. Then I did a subgit verify, which failed.
Any ideas? Unfortunately I can’t verify with 2.0.3, that doesn’t seem to have that command.
git@gitlab:~/git-data/repositories/@hashed/4b/22$ subgit verify 4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a.git
SubGit version 3.3.15 ('Bobique') build #4442
(c) TMate Software 2012-2021 (http://subgit.com/)
Verifying repository at '/var/opt/gitlab/git-data/repositories/@hashed/4b/22/4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a.git'.
SVN revision 10 is missing in Git repository.
SVN revision 11 is missing in Git repository.
SVN revision 13 is missing in Git repository.
SVN revision 12 is missing in Git repository.
SVN revision 17 is missing in Git repository.
SVN revision 18 is missing in Git repository.
SVN revision 19 is missing in Git repository.
SVN revision 20 is missing in Git repository.
SVN revision 21 is missing in Git repository.
r24 verified | 0% [ ]error: Cannot resolve refs/svn/root/branches/Feature_CreateDetail_ConvertFail_CrossSection for repository at /var/opt/gitlab/git-data/repositories/@hashed/4b/22/4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a.git
error: Unexpected error has occurred; please report along with the logs ('/var/opt/gitlab/git-data/repositories/@hashed/4b/22/subgit-verify-20220908-085855.zip')
error: to https://support.tmatesoft.com/, thank you!
subgit-verify-20220908-085855.zip (2.7 KB)
Hello Michael!
Thank you for reaching out to us on this matter!
Such an issue may be caused by the repository corruption, it is especially possible with such an old version as 2.0.3 that is very old version. However, considering that the repository was working fine prior to the migration and the error message the verify shows, I’d rather suppose that some of the SubGit metadata is just missing. You’ve mentioned that ‘subgit’ and ‘svn’ directories were moved, but I’m not sure about the svn references – those reside in the refs directory in the bare repository, are they present in the imported repository?
Hi,
I had indeed missed the refs/svn subdirectory, but it doesn’t change a thing. I did some more testing meanwhile, in particular a subgit install --rebuild, and while it fixed the repository it destroyed the commit hashs from a certain point onwards. Which seems to result from a duplicate commit sometime back in 2013. Subgit 3.3.15 doesn’t create that particular duplicate, resulting in different hashs from that point onwards. Seems my repository is broken and I’ll just have to rebuild it.
Talking about rebuilding, as changing the authors mapping of course results in changed hashs too, is there a way to configure subgit to not allow any svn commits that has no author listed in the authors file? To force the admin to adjust authors.txt as soon as a new user shows up in svn?
Hi Michael,
The rebuild is indeed an ultimate solution that would definitely resolve such an issue, but you’re right, the rebuild may lead to commit hashes change depending or current configuration and authors mapping. The install --rebuild in fact a new import from scratch: this SubGit command actually backups the old repository and then re-imports the whole repository from the very beginning using the current SubGit configuration. So if you need your old not rebuilt repository back, it should be there on the filesystem beside the new one (actual GitLab project directory), but it probably should be imported once again.
I’m afraid SubGit has no such a feature to disable translation if the SVN authors is not in the authors mapping. It is possible to do so for the opposite direction declining commits if they do not conform rules by adding such a functionality to SubGit’s pre-receive hook or adding custom user-pre-receive hook, but for the commits from SVN this won’t work.
I decided to go down the rebuild route, thanks for the info about the backup.
Maybe it would be a nice feature to add such a block for svn commits? I wonder if it may be possible to cause a deliberate error from the authors helper program. What would happen in that case?
Hello Michael,
we will discuss it will the development team and add it if it would be possible.
I’m afraid, such a trick would not work either: if SubGit gets and error from the authors helper program, it just uses the “automatic” authors mapping – that is, it generates a Git name taking the SVN author name as a user name and email consisted of the SVN username and the default domain. So the revision will be translated no matter if the helper program returns an error or not, but if it does, then the new commit author will be set according to the automatic authors mapping, which would be the same name as in case when the name is not found in the mapping.
Hi,
that would be much appreciated.