SVN to GIT conversion throws error to delete .lock file

Hi,

Can anyone help me to resolve the .lock file issue during SVN to GIT conversion? Image attached for reference.

Error : Delete the lock file…

[image]

Hello ManoChitra

I’m afraid the image has not been attached, could you please re-send it once again? Also, could you please share some details on the issue – namely, when exactly does it happen, how many repositories are affected and what is the system you run SubGit on?

Hi Ildar,

Glad to see rapid response! Attached the screenshot now and below are additional info.

I’m working on 32 repositories and so far two repositories are shown this error and 10 repositories are success without any issues.

SubGit is in Windows system.

I use the below command to convert local SVN repository into local GIT. During 100% completion of conversion process, it shows error to delete .lock files.

subgit import --default-domain…etc.

Error delete lock file.docx (75.9 KB)

Thanks!

Hello ManoChitra,

thank you for the screenshot and explanation.

Judging from what SubGit shows in the message, the issue does not relate to the lock file – SubGit just informs that it deletes the lock file, but the main issue was that SubGit was not able to update the reference in the Git repository:


Since the import is running on Windows, I’d guess that the most probable cause is an antivirus software that blocked files in the Git repository at the time SubGit was trying to update them, so I would recommend to disable the AV software or at least to exclude the Git repositories paths from the AV checks. If there is any other software that could lock files in the background, I would recommend to disable them, too, for the time of import or somehow exclude the Git repositories so that they are not affected by this software.
As for the failed import, it can be continued (as soon as the blocking conditions are cleared) with the following command:

subgit install REPO_PATH

REPO_PATH here stands for the path to the Git repository. This command will start a mirror, so it should be stopped after the initial import is done:

subgit uninstall REPO_PATH

or

subgit uninstall --purge REPO_PATH

The latter will also remove all SubGit metadata from the repository.

Also, I’ve noticed you are using SubGit 3.3.11 which is a bit obsolete as of now, I would recommend using the latest version 3.3.14 we have released recently.

Hi Ildar,

Sorry to respond with delay. It is not that clear to understand that the SUBGIT deletes the .lock file. Also, this occurred for couple of repositories so far and not sure about upcoming migration repositories.

One more thing is, why this Anitivirus software did not create any issues for other few repositories that are migrated and it it occurs only for these two repositories?

I’m not really sure whether it is recommended to disable the Antivirus software in production server.

Kindly help me to understand.

Regards,
Mano.

Hello Mano,

SubGit creates a .lock file at the initial import and deletes it on the import finish or in case of any import fault. In this particular case, a fault occurred and SubGit just removed the .lock file and informed about that, but, as I mentioned, removing the .lock file was not an issue per se, the main issue was that SubGit was unable to update the refs/tags/Formal_Run_1 reference in the target Git repository and the import failed due to the issue. The reason why SubGit was unable to update the reference is not clear, SubGit just had no such information, but most probably it happened because some other process was blocking the reference and thus prevented it from update. On Windows it often happens that an AV software blocks the files, so AV software is the first thing we recommend to check out in such cases. I’m not sure why AV software (or other process) blocks this reference and does not touch other references and repositories, it may be related to some signatures AV software recognises, probably.
As for the AV disabling – it’s probably not the best idea to disable it completely, but the main idea here is to prevent the AV software (or other process) from affecting the repositories being imported. So it’s probably could be allowed to disable it temporarily for the time of importing the repositories, or, alternatively, set the AV to not to check some particular paths so that it’s not checking the newly imported repositories.

Hi Ildar,

Sorry to bother you again!

I would like to know if there are any other options available to overcome the .lock files issue in converting SVN repo into local GIT compatible. Because anything related to Antivirus is not helping us to resolve the issue.

Kindly help/guide me here. As mentioned earlier, out of 32 repositories, this .“delete lock file” issue occurs only for 4 repositories.

Thanks
Mano

Hi Mano,

this is not a known issue that could be easily eliminated, as we discussed earlier, this looks to be specific for this particular setup and thus requires a deeper investigation to be resolved. May I ask you what were the actions related to the Antivirus that you tried to perform: have you tried to exclude those repositories from the all the AV checks? Have you tried to switch the AV off completely? Have you checked out the AV logs and were there any signs the AV affects the repositories? Also, is there any other software in the system besides the AV that may lock the files so that SubGit process is not able to handle the files?
Could you please advise what is the difference between the affected 4 repositories and those that are not affected? Are they of different size, is the changes rate different, do they all contain binary files or not? Please collect all the SubGit logs from one of the the affected repositories (let’s select one of them as the investigation target) and from one that is not affected .