Кто-нибудь знает альтернативу Polarion для миграции Starteam (2006v2) на SVN? Один только наш источник занимает 10 ГБ, не считая всей истории изменений. Каждый раз, когда я запускаю Polarion svnimporter, я получаю исключение «Java out of memory». Я не уверен, что вызывает использование всей памяти, но я не совсем уверен, что делать дальше. Любые предложения (которые позволят мне хотя бы сохранить некоторую историю) были бы очень признательны.
Спасибо!
Около десяти лет назад мы провели миграцию StarTeam на ClearCase. Меня наняли для написания программы миграции. К сожалению, StarTeam имеет крайне ограниченный интерфейс командной строки и не имеет реального API. Почти все команды StarTeam должны были быть предварительно зафиксированы строкой входа в 50 символов. Возможно, это изменилось за последнее десятилетие.
Вы пробовали увеличить выделение памяти для Java? По умолчанию JVM будет использовать только 64 МБ памяти. Многим Java-приложениям нужно гораздо больше. В команде Java вы можете дать ему что-то вроде -Xmx256m, чтобы получить 256 мегабайт памяти. Я вижу, что программное обеспечение Polarion основано на Java, но я не стал его загружать, потому что им нужны были мое имя и адрес электронной почты. (Это просто не стоит хлопот.) Однако я так понимаю, что существует пакетный сценарий или сценарий оболочки, который выполняет программу.
Можно ли одновременно делать только один или два каталога / модуля? Многие сайты используют несколько репозиториев Subversion - по одному для каждого модуля - вместо одного большого репозитория для всех модулей вместе. Кроме того, вы всегда можете сбросить и загрузить все репозитории Subversion в один большой репозиторий, если вы действительно этого хотите. Еще немного смазки для локтей, но если это сработает, вы сохраните всю свою историю.
В итоге мы просто преобразовали несколько отмеченных точек для истории, а не все. Наша теория заключается в том, что если вам действительно нужна подробная история, вы можете вернуться в репозиторий StarTeam.
То, что произошло, изменило мой взгляд на эти вещи: правда в том, что мы все равно не могли создать большую часть старого материала, поскольку это зависело от того, как это было в StarTeam, поэтому даже если мы сохранили историю, это не помогло нам много добра. И это также дало нам возможность реструктурировать все и выбросить устаревшее - то, что мы, вероятно, не сделали бы, если бы действительно могли сохранить историю.
И, в конце концов, историю все равно никто не упустил. Репозиторий StarTeam использовал SQLServer для обслуживания базы данных репозитория. Эта база данных вышла из строя вскоре после преобразования. Мы узнали об этом почти год спустя. Я просто пытался проверить, работает ли StarTeam, и обнаружил проблему.
Итак, посмотрите, помогает ли увеличение объема памяти процесса Java, или посмотрите, сможете ли вы выполнить преобразование по частям. Если это не помогает, вы можете спросить себя, действительно ли нужно возвращаться к истории, или все в порядке, если вы просто сделаете несколько отмеченных пунктов и подсказок активных веток.
Если кому-то действительно нужна история, можно вернуться к старой системе StarTeam.
Хотел бы я оказать вам дополнительную помощь, но мне самому со StarTeam не повезло.
Неужели командный интерфейс StarTeam настолько плох? Должна быть возможность написать простой скрипт для перечисления ревизий, а затем проверить их из стартовой группы и в SVN в большом цикле или что-то в этом роде, не так ли?
Вы так думаете. В конце концов, мне удалось написать свои собственные процедуры преобразования для ClearCase, CVS, Subversion во что угодно. Однако, когда я сделал это десять лет назад, интерфейс командной строки StarTeam был ужасен, документация ужасна, а Borland (которому принадлежит StarTeam) совсем не помог.
Для инструмента командной строки нет входа. Каждая команда должна предоставлять учетные данные, что означает ввод строки из 50 или около того в каждую команду. Это также означает, что интерфейс командной строки не имеет представления о том, на что вы на самом деле смотрите. Вы не можете выполнять команду типа svn info. Вы только что проверили кучу вещей.
Невозможно просмотреть подробную историю через командную строку. Например, нет способа узнать все версии и проверять их по одной, как в случае с Subversion или даже CVS.
Существовал C API, но он также был довольно ограничен. Я вижу, что теперь есть Java API, который, вероятно, использует Polarion.
Я подумал, может быть, есть пакет StarTeam для CVS, который может немного помочь. После преобразования в CVS вы можете преобразовать его в Subversion. Увы, за исключением нескольких душ в мрачном мире Интернета, задающих тот же вопрос, я не смог найти ничего по этому поводу.
Я попытался загрузить информацию об API или документацию по командной строке, чтобы посмотреть, смогу ли я что-нибудь понять, но веб-сайт не работает.
Извините, я не могу вам помочь, кроме как Я пытался и потерпел неудачу.
Я нахожусь в процессе миграции проекта среднего размера из StarTeam в Subversion. Мне тоже приходилось иметь дело со многими сбоями JVM из-за нехватки памяти. Похоже, что либо библиотека / инструмент Polarion, либо файл StarTeam.jar, который они используют из StarTeam, имеют огромную утечку памяти. В любом случае, похоже, я преодолел это (скрестив пальцы), выполнив следующие действия:
java -Xmx2048m -cp svnimporter.jar:starteam80.jar org.polarion.svnimporter.main.Main full config.properties
Теперь он работает около 3 дней примерно с 11 тысячами файлов ... и завершен только наполовину ... так что это, по меньшей мере, МЕДЛЕННЫЙ процесс.
Я не нашел других инструментов ... так что удачи.
Я не знаю Starteam, но обычно вы можете экспортировать список меток / тегов (или, может быть, всех тегов?) Из вашей системы управления версиями исходного кода. А затем используйте svn_load_dirs.pl, чтобы «наложить» их друг на друга.
Это означает, что у вас будет не вся история, а, по крайней мере, большинство состояний замороженного проекта.
Вы также можете экспортировать или не экспортировать некоторые версии с отметкой времени и также попытаться сложить их в стопку.
Недавно я перенес несколько простых VOB в прозрачном регистре, просто изучив историю проверок / фиксаций, экспортировал для каждой проверки полную версию проекта и использовал svn_load_dirs.pl для их импорта в новый репозиторий svn.
https://stackoverflow.com/users/618865/quinn-bailey ‹= Этот парень уже делал конверсии раньше и написаны исправления. Может помочь.
https://www.openmakesoftware.com/svn-importer-converting-from-borland-starteam/
есть несколько интересных комментариев по этому поводу. Я также знаю, что у SVN Importer есть проблемы с импортом ревизий с более чем одной меткой. Я слышал, что была версия SVN Importer, которая могла бы это обойти, но пока не могу ее найти.
