Hello,

Thank you for reporting this problem.

Try to increase memory available for subgit process:

1. Open in editor $SUBGIT_INSTALLATION_DIRECTORY/bin/subgit file;

2. Find the following line:


3. Change this line to


Try different sizes in '-Xmx<size>M' variable.

Please answer the following questions, in order to understand what could cause the failure:

• How much physical memory available on your machine?
  
• Does you repository have a lot of directories in the latest revision? Thousands or millions?
  
• Did this message appear in terminal?

I have 8GB in a MacBookPro. Number of toplevel directories is about 100. Recursively I have 2344 directories. I have about 2500 tags and 60 branches in about 70,000 commits. The message does not appear!

Could you please provide the whole output of 'subgit configure' before it fails. Does it print the following line? Is that the last line in the output?

yes, this line is printed. But no progress on revisions.

This is the whole output:

SubGit version 1.0.0-EAP ('Miai') build #1096
This is an EAP build, which you may not like to use in production environment.

Detecting paths eligible for translation...

Exception in thread "Poller SunPKCS11-Darwin" java.lang.OutOfMemoryError: Java heap space

 at sun.security.pkcs11.wrapper.PKCS11.C_GetSlotInfo(Native Method)

…

 at sun.security.pkcs11.wrapper.PKCS11.C_GetSlotInfo(Native Method)
 at sun.security.pkcs11.SunPKCS11.initToken(SunPKCS11.java:767)
 at sun.security.pkcs11.SunPKCS11.access$100(SunPKCS11.java:42)
 at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:700)
 at java.lang.Thread.run(Thread.java:680)

CONFIGURATION FAILED

Error have occurred (see details below), restoring original state.
error: Java heap space
error: Unexpected error has occurred; please report along with the logs ('/Volumes/Macintosh Home/eric/CGAL/gforge/subgit-configure-20120311-131433.zip')
error: to http://issues.tmatesoft.com/, thanks!

Increasing the memory seems to help. It is running much longer (or in an endless loop,... )

Meanwhile you may try create $SVN_REPOS/conf/subgit.conf file with the following contents:

[core]
shared = false
logs = subgit/logs
errorReport = subgit/error
authorsFile = conf/authors.txt
[git "default"]
translationRoot = /
repository = .git
pathEncoding = MacRoman
trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
shelves = shelves/*:refs/shelves/*
tags = tags/*:refs/tags/*
[daemon]
pidFile = subgit/daemon.pid
idleTimeout = 0
classpath = subgit/lib

Add and adjust 'git' sections for every subproject in your repository.

You may also create conf/authors.txt file in order to map svn authors to git identities, the format is as follows:
SVN Author = Git Author <git.author@domain.com>

Done. Waiting .. beyond: It would be great to interrupt (read: to resume) the configuration, that is, I am doing this remotely and thus restarting after network outage is time consuming.

So, you have the repository configured and now installation is in progress, right?

'subgit configure' must be fast operation, it shouldn't take that long even on large repositories. Most probably we will shrink the scanning depth in order to make it faster.

'subgit install' indeed is a heavy operation. We have 'resume the installation' feature in mind, but we decided to postpone with it, since there's a workaround to use 'screen' for remote subgit installation via SSH. See http://www.bangmoney.org/presentations/screen.html

Hi,

no configure runs and runs and runs (last putput is "Detecting paths eligible for translation...").

It seems that I can interrupt it and then start "install" which takes reaaaallly long.

Hello Eric,

subgit configure command just generates $SVN_REPOS/conf/subgit.conf file. You may create this file by yourself and adjust it as you need for your particular repository. So, no need to run this command and wait until it's done.

subgit install command is quite expensive indeed:

• For repository of ~1 000 revisions it takes ~8 minutes to convert everything from svn to git;
  
• For repository of ~10 000 revision it takes ~40 minutes to convert;
  
• A lot depends on repository layout, i.e. are there a lot of projects in FSFS instance, how many branches and tags are there, history complexity, etc.
  
• The disk latency matters a lot, network attached storage is usually bad option to work with.

I'd estimate the time needed to convert your repository by install command as ~5-7 hours.

Hi, thanks for the detailed information (can you add a sentence that the only purpose of "configure" is to create the conf file, this avoids confusion and helps more advanced users). I've created the file by myself and additionally ignored many many many tags (now < 100 tags). The first 23000 tags are converted quickly (less then 1h), but then the process significantly slows down. Only a few revisions per minute. Can this be a memory problem? (java is stable at about 800MB of RAM, and there is about 900 MB still free and 1800MB inactive). p.s. everything is on a local SSD.

Hi,



Help prints the following message:

$ subgit help configure
info: Create SubGit configuration file to be used by 'install' command.

Probably help output should include the statement that this operation is assumed to be fast.

That's interesting behavior. Do the branches and tags in your repository have svn:mergeinfo property set? Can you please send us the output of the following command for a few recent branches and tags?

svn propget svn:mergeinfo $BRANCH

Thanks for the update. The values of svn:mergeinfo property are fine on your branches, they couldn't influence the overall performance in your case.

There are some other reasons for the slow-down:

• A lot of big files modified in certain revisions;

Even 1mb file may slow down conversion after it was added into a pack file. Could you please check that those revisions converted too slowly has modifications of such files.

• Modifications of svn:eol-style and svn:mime-type lead to a huge .gitattributes file located in the root directory;

Could you check that converted git repository doesn't have such a huge .gitattributes file?

Java memory/garbage collector issues don't seem relevant here so far.