Существует ли способ переместить SourceSafe с ИСТОРИЕЙ в SVN?
Если я правильно понял ваш вопрос, вы ищете что-то для составления командной строки с использованием переменных. Вы можете сделать это несколькими способами, это один (используя функцию Format ):
var
IPAddress : string;
begin
IPAddress := '192.168.100.1';
ShellExecute(
Application.Handle,
'open',
'cmd.exe',
PChar(Format('/c "mysqldump -h %s -uroot database table > C:/Users/user1/Desktop/export.sql"', [IPAddress])),
nil,
SW_SHOW
);
end;
7 ответов
Давным-давно (это кажется), я попытался переместить SourceSafe DB в подверсию с помощью vss2svn, но наконец сдался. Было несколько проблем, IIRC:
- необходимо удостовериться, что DB SS последователен (например, Проанализируйте, не находит проблем или может зафиксировать их).
- потребовалось очень долгое время для миграции DB, потому что это было довольно большим.
- наконец миграция перестала работать из-за некоторых проблем с парсингом дат. Я не смог найти причину проблемы, но я предполагаю, что это было вследствие того, что мы используем формат даты DD.MM.YYY вместо американского формата даты.
Таким образом, наконец мы решили сохранить в целости SourceSafe DB (только для чтения) и просто переместить текущую версию в подверсию. До сих пор было очень немного случаев, куда мы должны были вернуться в SourceSafe для проверки чего-то.
Надеюсь, это поможет.
BTW: не имеет значения, используете ли Вы Сервер VisualSVN или подверсию непосредственно (svnserver). Формат репозитория является тем же в обоих случаях.
Да, используйте проект VSS2SVN на Codeplex. Я обновил его так, это поддерживает историю, комментарии, автора и свойства даты при миграции на SVN. Берет немного дольше, но я надеваю; t думают, что вопросы как не что-то Вы каждый день делаете.
Это также имеет опцию обновить репозиторий с файлами от VSS мимо определенной даты, таким образом, можно обновить начальный дамп позже.
Мне успешно удалось переместить несколько источников безопасные репозитории в SVN, использующий vss2svn сценарий. Мои предложения, сделайте это в маленьких блоках - у нас было много небольших проектов и нескольких средних параллельных проектов, которые всем удалось быть перемещенными успешно в SVN.
У меня было несколько проблем:
- Большим файлам не удалось быть записанными в в формат файла дампа SVN, я отправил патч, чтобы заставить его работать, я думаю, что кто-то записал этому немного больше sophisticatly после того, как я был сделан.
- Структура корневого каталога не была скопирована через правильно. Репозиторий VSS был организован как $/client/project. Репозиторий SVN закончил тем, что был организован как svn://server/randomdirectory/anotherrandomdirectory/client/project. Таким образом, я зафиксировал их путем редактирования dumpfile прежде, чем импортировать его (я думаю, что это была замена находки "/randomdirectory' с ''.
Мы использовали Polarion SVN Importer для миграции VSS в SVN с полной историей.
В своей компании я неоднократно пытался мигрировать (большой) репозиторий SourceSafe на Subversion с помощью vss2svn. Я даже внес небольшой вклад в поддержку кодовых страниц (у нас были имена файлов на греческом языке). Если я правильно помню (это случилось весной прошлого года, т.е. 2009 года), наша главная проблема (та, которая заставила нас окончательно отказаться от миграции) заключалась в том, что постоянно удаляемые файлы, которые были сшиты/перемещены между разыскиваемой и нежелательной частью репозитория, блокировали миграцию.
Мое предложение: Если вы не можете сделать это в полностью Analyzed репозитории, не тратьте больше времени. Просто нарисуйте линию и начните с нового репозитория Subversion.
Примечание: Постоянное удаление файла в SourceSafe делает файл полностью невосстановимым, что является чем-то совершенно несовместимым с системами управления исходным кодом типа CVS/SVN- (а также, я полагаю, с другими системами управления исходным кодом).
.Я успешно преобразовал нашу неприятную базу данных VSS, включая историю. О своем опыте я пишу в блоге здесь. Изюминкой преобразования является:
"Все инструменты преобразования также требовали, чтобы исходная база данных VSS была очищена от повреждений перед преобразованием. Это оказалось намного сложнее и трудоемче, чем вы могли подумать. Запуск инструмента VSS Analyze на копии базы данных показал сотни повреждений и не завершился бы без просеивания синим цветом компьютера, на котором он работал.
Чтобы обойти это, мы уменьшили базу данных, удалив каталоги, которые мы не хотели преобразовывать. К сожалению, VSS будет сообщать о каждом повреждении во время процесса удаления, вызывая сотни ящиков с сообщениями, которые пользователь должен бездумно кликнуть для продолжения процесса.
Как только эта точка была достигнута, мы использовали инструмент VSS2SVN для создания файлов дампа, которые были импортированы в Subversion"
.