I rebuilt my git project using subgit install --rebuild
After the rebuild, one of my branches became missing, although the derivative branches for the individual developers are there. The branch is still there on the svn side though. I don’t see anything in the logs that would give me a clue on how this branch (2.0) became missing?
Hi Gavin,
I may only assume that the branch has been somehow excluded from translation by the mapping configuration, there are no more settings that could cause that. It’s hard to tell what that was, however, should be investigated further. Could you please provide us with SubGit logs for analysis? We are particularly interested in rebuild log, daemon and hooks logs.
Hi Ildar,
Sorry for the delay. Here are the log files. rebuild_subgit.tar.gz (2.4 MB) There wasn’t a specific rebuild log, so I’m assuming its in the install log.
Hi Gavin,
thank you for the logs.
Could you please advise what is the branch missing in the repository?
Hi Gavin,
also, could it be possible to provide us with the listing of your repository “branches” directory and “git for-each-ref” output from the subgit repository?
Ildar,
The missing branch is 2.0.
sh-4.2$ pwd /var/opt/gitlab/git-data/repositories/hms/hms-jhs.git/refs/heads sh-4.2$ ls 1.2.4_new_folders 1.2.6_R1U 1.2.6a 1.2.8 2.0 2.0_dependency 2.0_roy master 1.2.5 1.2.6 1.2.6_RM7179 1.2.7 1.2.8_8807 2.0_RJ 2.0_nellie ian_2.0 sh-4.2$ cd ../../branches sh-4.2$ ls sh-4.2$
So the branches directory is empty, but the refs/heads has the 2.0 folder. However, this 2.0 folder doesn’t show up in the UI, nor is it available when doing a git pull.
Not sure what you mean by “git-for-each-ref”
Hi Gavin
‘git for-each-ref’ is actual git command that can be run in the SubGit repository and that lists all the references in the repository. Could it be possible to run that command?
And also, could it be possible to provide us with the ‘branches’ directory listing, not ‘branches’ in Git but rather ‘branches’ directory in SVN repository. It would also be great to have SVN log for that branch. And I’ve got a question about it, could it happen that the SVN user used by SubGit has any permissions limitation accessing that path in SVN (branches/2.0)?
Ildar,
Here is the output of the command:
d22fd6257ed6ac0b2a67f5a4e13ecda8d308cb49 commit refs/heads/1.2.4_new_folders 99b91d1d9c3be6986968ba1ef3e69cfb056fd3b3 commit refs/heads/1.2.5 8d6424f8523a07cc32b55808e58bc0ef69b525be commit refs/heads/1.2.6 0e033f1321cfb44d9895a17d5ddca3d606d8df07 commit refs/heads/1.2.6_R1U 93a4464dba2d1529fa74c4cefaee61fc10c2ddd0 commit refs/heads/1.2.6_RM7179 59c60cb80d37d202db41ca1d2724b07be00ba764 commit refs/heads/1.2.6a fa9359818e16606b7984e52e4e2201f8b25875e8 commit refs/heads/1.2.7 c6d68e844a0c0792f7badc8671e7d50743e1c572 commit refs/heads/1.2.8 52e4fddb85762a291edd19be6dc301d0e328d724 commit refs/heads/1.2.8_8807 a3e6c4591da53df549a17639a278627024166b53 commit refs/heads/2.0 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/heads/2.0_RJ 192207439ca7afe282bb8af56d663401ff83ed5f commit refs/heads/2.0_dependency 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/heads/2.0_nellie 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/heads/2.0_roy 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/heads/ian_2.0 7874c2aaed078cc5a92d82bd12b31ac2dd6f7049 commit refs/heads/master 8356660db0186f358b293d6eca225ef836e09843 commit refs/svn/map d22fd6257ed6ac0b2a67f5a4e13ecda8d308cb49 commit refs/svn/root/branches/1.2.4_new_folders 99b91d1d9c3be6986968ba1ef3e69cfb056fd3b3 commit refs/svn/root/branches/1.2.5 4df936d66eb561f1743cb1ab452782c9d48bb16e commit refs/svn/root/branches/1.2.5_NGEMR_EPIC_WS 8d6424f8523a07cc32b55808e58bc0ef69b525be commit refs/svn/root/branches/1.2.6 0e033f1321cfb44d9895a17d5ddca3d606d8df07 commit refs/svn/root/branches/1.2.6_R1U 93a4464dba2d1529fa74c4cefaee61fc10c2ddd0 commit refs/svn/root/branches/1.2.6_RM7179 59c60cb80d37d202db41ca1d2724b07be00ba764 commit refs/svn/root/branches/1.2.6a fa9359818e16606b7984e52e4e2201f8b25875e8 commit refs/svn/root/branches/1.2.7 c6d68e844a0c0792f7badc8671e7d50743e1c572 commit refs/svn/root/branches/1.2.8 52e4fddb85762a291edd19be6dc301d0e328d724 commit refs/svn/root/branches/1.2.8_8807 a3e6c4591da53df549a17639a278627024166b53 commit refs/svn/root/branches/2.0 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/svn/root/branches/2.0_RJ 192207439ca7afe282bb8af56d663401ff83ed5f commit refs/svn/root/branches/2.0_dependency 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/svn/root/branches/2.0_nellie 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/svn/root/branches/2.0_roy 8b179125c98496ed2e618eb4e9de77c25d5f0dad commit refs/svn/root/branches/ian_2.0 46f27e40d80199d79dadb5ac277a4c448c33d2d4 commit refs/svn/root/tags/1.2.3 99b91d1d9c3be6986968ba1ef3e69cfb056fd3b3 commit refs/svn/root/tags/1.2.5 84205392966ed9dbff1335afbf19b79efd50a011 commit refs/svn/root/tags/1.2.5_6996 fa9359818e16606b7984e52e4e2201f8b25875e8 commit refs/svn/root/tags/1.2.7 c6d68e844a0c0792f7badc8671e7d50743e1c572 commit refs/svn/root/tags/1.2.8 52e4fddb85762a291edd19be6dc301d0e328d724 commit refs/svn/root/tags/1.2.8_8807 7874c2aaed078cc5a92d82bd12b31ac2dd6f7049 commit refs/svn/root/trunk 46f27e40d80199d79dadb5ac277a4c448c33d2d4 commit refs/tags/1.2.3 99b91d1d9c3be6986968ba1ef3e69cfb056fd3b3 commit refs/tags/1.2.5 84205392966ed9dbff1335afbf19b79efd50a011 commit refs/tags/1.2.5_6996 fa9359818e16606b7984e52e4e2201f8b25875e8 commit refs/tags/1.2.7 c6d68e844a0c0792f7badc8671e7d50743e1c572 commit refs/tags/1.2.8 52e4fddb85762a291edd19be6dc301d0e328d724 commit refs/tags/1.2.8_8807
The branch was present before the rebuild, but disappeared after that, so shouldn’t be an accessibility issue
I attach a screenshot of the SVN branch directory
Hi Gavin,
could you please run the following command in the GitLab server console:
gitlab-rake cache:clear
This command requires root permissions and it clears GitLab UI cache. After the command finishes successfully, please check if the branch appears in the UI and can be pulled in the working copy.
If the problem persists, please try to clone the repository using file protocol on the GitLab server:
git clone /var/opt/gitlab/git-data/repositories/hms/hms-jhs.git ~/hms-jhs
Step in the cloned repository
cd ~/hms-jhs
and the try to pull the 2.0 branch.
Hi Ildar,
I tried the cache:clear, but it didn’t work.
However, cloning from the filesystem and pulling the 2.0 branch works. What should be the next step?
Hi Gavin,
thank you for letting me know.
This is pretty interesting, however: the fact that the repository is being cloned correctly over the file protocol indicates that the repository itself (and the references in it) is OK and works well, otherwise it would not be cloned. So the issue looks more like a GitLab issue rather than issue related to SubGit operations – it arises when the repository is being cloned (or accessed) over GitLab’s facilities and GitLab does not show the branch in the UI despite the branch itself is OK. The only known issue in SubGit-with-GitLab setup is that it happens sometimes that GitLab’s cache is not being updated after the initial translation of an SVN repository and its data is not being shown in GitLab UI properly – but it only affects UI representation, cloning and other Git operations works well. And even that UI issue is being resolved by the cache cleaning.
So I suggest try to check GitLab first. Could you please let us know what is GitLab version you are using and the setup details – where GitLab and SubGit are installed, where do the repository reside, etc. Also, could you please try to restart GitLab and check if the issue persists?
Ildar,
We are using Gitlab 12.4.2, and Subgit 3.3.9 4351. I tried rebuilding, and the 2.0 branch appears, but some new branches created on the Git side disappeared or was reported as corrupted.
Seems like I had no other choice but to trash the project and start again from scratch. Had all kinds of problems from corrupted refs and missing branches on this project.
Hi Gavin,
it may make sense, indeed. We are not yet sure what the issue is: actually, GitLab 12.4 is OK, we have never met issues like that with nowadays GitLab versions (v12 is obsolete already, but not that old). SubGit 3.3.9 is also ok, yet it may worth to update it to the latest 3.3.10; but 3.3.9 had no issues like this as well. So the issue itself seems to relate to your particular setup, but it’s not yet clear what exactly may cause it. Re-translating the repository from scratch would definitely ends up with a proper repository and we will be able to trace the issue if it will happen again.