Initial translation is notably slow, is it possible to speed it up?

At the average, one revision translation takes 1 - 1.5 seconds. Of course, the bigger number of revision is, the longer is the translation. If it runs much slower, though, there are few things to consider:

• most often, slow translations is caused by incorrect branches and tags mapping configuration. The most recommended way to create correct configuration is to use ‘subgit configure’ with ‘layout auto’ option:

        $ subgit configure --layout auto --trunk TRUNK_PATH SVN_PROJECT_URL [GIT_REPO_PATH]
  

  where

  • TRUNK_PATH - a path, relative to the SVN_PROJECT_URL, that leads to the directory playing a role of ‘trunk’ or ‘main line’ of development in the SVN project.
  • SVN_PROJECT_URL - a URL that points to a single project in SVN repository, that’s intended to be translated to Git.
  • GIT_REPO_PATH - an optional path to a new Git repository, where the SVN project will be translated to.

  As an example, the command may look like this:

        $ subgit configure --layout auto --trunk main http://example.com/svn/repository/project /home/user/project.git
  

  SubGit will connect to the SVN project, scan its history and based on the TRUNK_PATH will try to find appropriate branches and tags and create valid mapping configuration.

  In rare occasions, though, the SVN project history and layout are so complex SubGit cannot create correct mapping configuration. In these cases the only way to set the mapping scheme is to create it manually following the mapping guide:

  BRANCHES AND TAGS MAPPING

  Another reason to change the mapping scheme manually is to exclude some branches, tags or particular files from the translation if they are not worth to be translated to Git. It can also speed up the translation, as the fewer branches and tags are in a mapping, the fewer revisions and data to translate.

There are a few more configuration options that can affect translation performance:

• an “EOLs translation” feature that tells SubGit to perform line endings translation for each file and this process may strongly affect translation performance. To improve translation performance that feature can be turned off in SubGit configuration file:

    [translate]
      eols = false
  

It has to be set before translation start.

• a stream file threshold that’s being set by the setting of the same name:

    [core]
      streamFileThreshold = <size in bytes>
  

It changes the way SubGit works with Git blobs: loads fully to memory or streams byte-by-byte from disk. Normally full loading is faster but may result into OutOfMemoryError.

• when streaming Git blobs, SubGit tries to use ‘git’ binary, that is expected to be found on the ‘gitPath’ path presented by ‘gitPath’:

    [core]
      gitPath = /path/to/git/executable
  

If SubGit doesn’t find Git binary, it uses internal means of streaming and they may be much slower.

• finally, a setting that sets Git Garbage Collector behaviour:

    [svn]
      triggerGitGC = [true|false|N]
  

by default, SubGit invokes ‘git gc –auto’ every revision and it may affect the translation performance. To speed up the translation, the GC can be either switched off (‘false’) or being invoked not so often (‘N’, a number of revisions between each invocation).

up

Does SubGit support .gitattributes macros?

Unfortunately, it does not. You will have to set up all attributes separately. To set the EOL’s properly for translation, use this guide.

up

Does SubGit translate svn:externals to Git?

Unfortunately, it does not. SubGit is only able to save the externals’ definitions in a .gitsvnextmodules file in the Git repository.

You may import your SVN repositories (the main one and all the external ones) separately and then combine them in Git, using our new tool for modular development in Git: Git X-Modules.

up

Does SubGit translate svn:externals to Git?

Unfortunately, it does not. SubGit is only able to save the externals’ definitions in a .gitsvnextmodules file in the Git repository.

You may import your SVN repositories (the main one and all the external ones) separately and then combine them in Git, using our new tool for modular development in Git: Git X-Modules.

up