SVN to GIT conversion throws error to delete .lock file


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

Error : Delete the lock file…


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)


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


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.


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.