search

rtcTo / rtc2gitcli

An IBM's RTC SCM tool extension to migrate an RTC repository into a Git repository
https://rtc.to
MIT License
28 stars 34 forks source link

Support large numbers and large sizes of changesets #39

Open snoop123 opened 7 years ago

snoop123 commented 7 years ago

Does this project support migration of large amounts of changesets, and large sizes of changesets? (we have changesets that contain hundreds of files)

Can I somehow fine-tune this process and improve running time? maybe by changing migration.properties parameters?

reinhapa commented 7 years ago

In principal this should be no problem. The way it works is that we create a git repo in a working folder, then checkout one change set at the time into this directory, then we add the changed files to the git repo and commit it using the time and committer informations of the RTC changeset

snoop123 commented 7 years ago

I understand the process, but could there be a scale issue? I see there are few parameters in migration.properties regarding heap / cache / windows size, but couldn't find instruction of how to define them. Could you maybe elaborate?

reinhapa commented 7 years ago

As far as I remember our migration we increased the packedgitlimit from the default 10m to about 500m as suggested in the following stackoverflow article. That's also the only tuning hint I know about. I hope this helps a bit...

ycon-company commented 7 years ago

Thanks!

himmakam commented 6 years ago

Hi, I have a very big project with large number of files and also changed the packagedlimit to 500m, but getting java.lang.outofmemoryerror java heap space. Any pointers here would be appreciated.

pjdarton commented 6 years ago

@himmakam Java OOM can be sorted by ensuring that JVM (Java Virtual Machine) arguments increasing the memory limit are passed to the JVM that's running the RTC CLI. It'll be something like setting JAVA_OPTS=-Xmx4g or editing the "scm" script to include the argument "-Xmx4g" to do that. Adjust "4g" (four gigs) to whatever is necessary - the default is pretty small.

FYI https://stackoverflow.com/questions/14763079/what-are-the-xms-and-xmx-parameters-when-starting-jvms has more info on what the argument means. The rest is just "plumbing" to ensure that the parameter gets passed to Java when the command "java " gets run.

I hope it works for you - I suspect I'm going to have to use this tool pretty soon myself...