Hello!
Thank you for your tool, it is very helpful.
We have GitLab with SubGit installation (commercial license).
We have a simple scenario:
-
Commit changes with subversion into the trunk
svn add newfile.txt
svn commit -m “Added file”
-
We want to pull the latest commit from git repository (git clone the same):
git pull --rebase origin
As the result we do not see any changes for 20 - 60 minutes on step 2. On GitLab web page the new commit appears immediately.
What’s can be wrong?
As a example:
$svn commit -m "New"
Revision: 27569
Author: me
Date: Thu Jun 18 11:34:13 MSK 2020
Message: New
Added newfile5.txt
----
Added : /subgit/trunk/newfile5.txt
$ date
Thu Jun 18 11:34:13 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 11:39:16 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 11:44:10 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 11:49:09 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 11:54:09 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 11:59:36 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 12:04:21 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 12:09:08 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 12:14:16 MSK 2020
Already up to date.
$ date
Thu Jun 18 12:19:12 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 12:24:11 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 12:29:11 MSK 2020
$ git pull
Already up to date.
$ date
Thu Jun 18 12:34:47 MSK 2020
$ git pull
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 6 (delta 3), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), 590 bytes | 84.00 KiB/s, done.
From http://gitlab.rlisystems.ru/rolis/subgit
3c8a8bd..4baea5b master -> origin/master
f51b536..f88dc58 refs/svn/map -> refs/notes/commits
Updating 3c8a8bd..4baea5b
Fast-forward
.gitattributes | 1 +
newfile5.txt | 1 +
2 files changed, 2 insertions(+)
create mode 100644 newfile5.txt
Here is a log logs (2).tar (450 KB)
Thanks in advance,
Anatoly Shirokov
Hello Anatoly,
judging from the description it looks like the issue does not relate to SubGit: the commits appear in GitLab UI after they’ve been imported by SubGit, so if they appear there immediately, that means that the delay is not being introduced during the SVN-to-Git translation. SubGit does not affect the ‘pull’ command in no way, too – it works when something is being pushed to a mirrored repository, but ‘pull’ is a pure Git operation even in a mirrored repository.
So my assumption is that this issue is a Git/GitLab related one. Could you advise how much local work do you have in your working copy? Could it be the case that you have too much local work and the rebase just is doing too much work? Does it happen to any commit you are pulling or to some particular ones? How does ‘pull’ works without ‘rebase’? And does it works this way in any repository on this server or only some of them?
Hi Anatoly,
looks I sent my previous message without noticing you edited yours. I have checked the log and found that the newfile5.txt has been translated to Git less than a minute later it was committed to SVN:
[2020-06-18 08:35:06.359][daemon][17] SET_PATH 'trunk' 27568 not empty depth=infinity
[2020-06-18 08:35:06.388][daemon][17] fetching: branch = refs/svn/root/trunk, revision = 27569, receivedFileCount=0
[2020-06-18 08:35:06.403][daemon][17] successfully received 'trunk/newfile5.txt' with size=9
[2020-06-18 08:35:06.411][daemon][17] For newfile5.txt "text" and "eol" are set to "UNSET" and "UNDEF" because svn:eol-style was changed to null or the file was added; and svn:mime-type was changed to null or the file was added
[2020-06-18 08:35:06.446][daemon][17] fetched: hash = 4baea5bf0367c403ca2c8aeb3e6677790cf061b9, branch = refs/svn/root/trunk, revision = 27569
Timestamps here are in UTC.
So the delay is definitely not caused at the translation stage, something is happening later, during the cloning the repository or fetching the changes. As I understood the issue is not specific for ‘rebase’, it also works this way for a regular clone or pull, correct? What about other repositories, especially not mirrored ones?
Thank you, Ildar!
Yep, the issue is related to any git operations: pull, fetch, clone.
Notably my colleague has switched from https on ssh protocol and now he sees all svn commits immediately.
It shows that the SubGit did its works.
Hi Anatoly,
thank you for letting us know! It’s quite strange though https causes such an issue, but glad to know there’s the ssh workaround.
@ildar.khusainov Ildar, could you join to the https://gitlab.com/gitlab-org/gitlab/-/issues/223200#note_370945597 discussion about direct writing into a git repository?
As I see GitLab has to provide special mechanism which can be used by SubGit to invalidate info/refs caching. It makes it works as expected via both http or ssh protocol for our case.
Hi Anatoly,
sure, we’ll get involved, we’re already discussing that internally.