Вопрос по git-svn, git – Сохранение истории копий svn при конвертации в git

6

Я пытаюсь преобразовать репозиторий SVN в несколько репозиториев git. До сих пор я использовалgit svn clone svn_repo_project_path для каждого проекта в SVN. Я заметил, что git, похоже, не выполняет операции копирования svn, поэтому итоговая история намного короче, чем я ожидал. Предположим, что мой репозиторий SVN выглядел так:

Корень

abc Родитель-проектируемыйbc

Проектыb а такжеc недавно были скопированы подparent-proj как часть усилий по реструктуризации с целью в конечном итоге удалить их из их старых расположений под root. Когда я делаюgit svn clone http://svnhost/parent-proj в полученном репозитории git отсутствует вся история, которая произошла от/b а также/c до переезда.

Это ограничение git-svn или есть какой-нибудь способ показать эту историю в моем репо? Из моего ограниченного исследования кажется, что использованиеfilter-branch команда, как описано в Получение полной истории репозитория SVN, который был переименован с помощью git-svn может работать, хотя в моем случае есть несколько родителей, что, вероятно, усложняет ситуацию. Может ли быть лучшим подходом клонирование всего репо, а затем выделение из него новых репо (с использованием filter-branch?)?

Перво наперво: svn правильно запоминает историю перед копированием проекта? Делатьsvn log а такжеsvn log --stop-on-copy и сравни результаты. Patryk Obara
Я не уверен, с какой версией они были клонированы. Я считаю, что изначально это был релиз 1.7 (это было несколько месяцев назад с последней версией Debian Wheezy). Однако недавно я вспомнил один из проектов с грязной историей, использующей v1.8.4, и он вел себя одинаково (некоторые SHA имеют совершенно разные деревья). Может быть, версия сервера SVN важнее? Я считаю, что это все еще на 1.7. Shadow Man
Может быть, тебе нужно немного освежиться? Я хотел посмотреть историю функции в моем git-репо (клонирован с помощьюgit svn clone) сегодня я искал stackoverflow и наткнулся на / Stackoverflow.com вопросы / 4908336 / ... который показал мнеgit blame -C MyFile, которая дала мне историю вины за функцию, которую я хотел, вплоть до исходного файла (который находился в другом каталоге), из которого был скопирован этот файл (исходный файл все еще существует в новом каталоге сегодня, но эти строки не дольше в нем). Shadow Man
@ ShadowCreeper: Какую версию Git вы использовали? У меня та же проблема, что и у Патрик Pylinux
Меня обвиняют в истории всех файлов, даже когда они перемещают каталоги. И мойgit svn clone также отслеживал проекты за пределами клонируемого каталога (откуда они произошли). Shadow Man

Ваш Ответ

1   ответ
0

b илиc если тыgit svn clone http://svnhost/parent-proj . git svn интерпретирует предоставленный вами базовый путь как самую мелкую точку, которую вы хотите использовать для принятия SVN-коммитов, а также для Git-коммитов. Как исторические коммиты подb а такжеc находятся за пределами этого пути,git svn не будет отражать их, поэтому у вас не будет этой истории.

Посмотрите на документацию дляgit svn init --no-minimize-url опция:

При отслеживании нескольких каталогов (с использованием параметров --stdlayout, --branches или --tags) git svn попытается подключиться к корню (или максимально допустимому уровню) хранилища Subversion. Это значение по умолчанию позволяет лучше отслеживать историю, если целые проекты перемещаются в хранилище, но может вызывать проблемы в хранилищах, где установлены ограничения на доступ для чтения. Передача --no-minimal-url позволит git svn принимать URL-адреса как есть, не пытаясь подключиться к каталогу более высокого уровня. Эта опция отключена по умолчанию, когда отслеживается только один URL / ветвь (это не принесет пользы).

С твоегоcloneоманда @ не задает несколько ветвей (возможно, из-за того, что у вас сложный, многопроектный или нестандартный макет),git svn просто клонирует коммиты с этим путем и вниз. Shadow Creeper в комментариях использовал символ-s или--stdlayout вариант, который может объяснить, почему для них сохранилась какая-то история.

Если это однократное преобразование (одностороннее перемещение из SVN в Git), то вам, вероятно, следует клонировать весь репозиторий, тогда у вас есть хорошие варианты перемещения вещей в Git, чтобы они выглядели так, как вам нужно, включая создание исторических веток и меток. Если мотивация для запускаfilter-branch предназначен для экономии места в хранилище, убедитесь, что это действительно что-то вас спасет, и что это стоит того. Git очень эффективен с хранилищем.

Последнее слово предостережения о поиске истории в клоне Git. Ищите историю в файле, используяgit log -C --follow <file-path> и Git, как правило, делают хорошую работу по поиску и предоставлению вам истории, включающей переименования и копии. Не ожидайте того же для каталогов, напримерparent-proj/b. Git отслеживает BLOB-объекты (файлы), деревья (BLOB-объектов), коммиты и родительские коммиты, но не обрабатывает каталоги или копии каталогов так же, как SVN.

Похожие вопросы