Subgit is stuck on "Translating Subversion revisions to Git commits..." for the first revision

257 views Asked by At

I try to use subgit to migrate a 12yo with 14.4kcommit svn repository to git.

My svn repo looks like this:

ProjectA/
    branches/
    shelving/
    tags/
    trunk/
ProjectB/
    branches/
    shelving/
    tags/
    trunk/

I only want to import it once and so I came with that cmd useing this documentation:

./subgit.bat import --svn-url http://<URL>/collectionOfRepositories/Repository1/ProjectA/ C:\Project1-subgit --default-domain unknownUser.com --minimal-revision 14300 --authors-file authors.txt -T trunk -b branches -t tags --username myUsername

No errors seems to occur but I get stuck on the first commit at 99% less than a minute in :

Translating Subversion revisions to Git commits...
r14300 => ad8d0ea3903771846aa8db32849223ab85c0ed03  |  99%  [||||||||| ]

I tried letting it process for an hour but the git project folder hadn't its size changed by 1 byte.

Following the same documentation I tried to use the subgit configure command with --layout auto but I get the exact same result.

I'm in a windows environment.

What am I doing wrong ?

1

There are 1 answers

3
ildar.hm On BEST ANSWER

Everything you're doing look correct, as well as that SubGit spends some time at that stage. The matter is that SubGit needs to download all the data repository contained at the revision 14300, as well as some other data. For any real-world repository it takes some time, especially if there were any big branches copyings in the history. For old repositories with long history initial replication may take even days, and hours may be considered expected. And that is also normal that the repository size does not change for some time -- most probably, SubGit is still downloading data to a buffer and hasn't yet written any data to the repository. If SubGit does not report any errors in the console and in logs, then everything should work well. This progress bar does not provide much information about the status, indeed, so better to check SubGit logs to make sure it's working. Depending on the initial replication stage, the logs may reside in the same directory where the command was invoked, inside the target repository (subgit/logs subdirectory), or in .subgit directory in current's user home directory.