2015-06-04 4 views
0

Я пытаюсь односторонней миграции из SVN в Git. Хотя все хорошо с большинством моих репозиториев, каждый раз через некоторое время я получаю «дубликаты» ссылок на данный тег SVN, и я не уверен, почему.Миграция из SVN в Git - повторяющиеся метки с помощью "@"?

В качестве примера можно привести моментальный снимок каталога SVO repo/tags, показанного с помощью репо-браузера TortoiseSVN. Обратите внимание, тег «657_RemoveTravellogProgressbar»:

SVN repo

При переходе на Git, если просмотреть содержимое .git/уплотненный рефов, то подавляющее большинство тегов вышли, как и ожидалось - одна запись каждый. Как ни странно, это «657» теги (и один другие) дают несколько записей, некоторые следует с @: -номером

07d524b93e8fc6957d06f687f83db0ba897890a9 refs/remotes/tags/657_RemoveTravellogProgressbar 
ee48ab8efa3f4ed5f54d0d1a3dd8fac76205ab9e refs/remotes/tags/[email protected] 
23eccb461e341a2f7bd0af03159c61600c888e7c refs/remotes/tags/[email protected] 

Для того, чтобы преобразовать мою удаленные тег SVN/ветвь к реальным Git тегам/филиалам в переносимом Сделки рЕПО, я использую следующие команды (из this удобного учебника):

git branch -r | sed -rne 's, *tags/([^@]+)$,\1,p' | while read tag; do echo "git tag $tag 'tags/${tag}^'; git branch -r -d tags/$tag"; done | sh 
git branch -r | grep -v tags | sed -rne 's, *([^@]+)$,\1,p' | while read branch; do echo "git branch $branch $branch"; done | sh 

После выполнения команды, я нажимаю мой перенесенный Git репо к оголенного репо & клона снова (чтобы удалить ссылки SVN). Если я затем просмотреть его график пересмотра с TortoiseGit, все, как и ожидалось ... для этого странного 657 тега, за исключением (и еще один) в сторону:

Git Revision Graph

Итак, вопрос: что это вызывает только эти два тега (из десятков) должны быть перенесены таким образом - где они заканчиваются несколькими ссылками в Git - в то время как 99% тегов выходят просто отлично? Каков правильный способ избежать этого (для достижения «согласованного» графика пересмотра)? Обратите внимание, что команды преобразования тегов/ветвей явно видят «@» в именах; ясно, что автор статьи знает, что это может произойти ... но я не могу понять, почему.

~ Добавление ~

Глядя на мой исходный граф пересмотра SVN репо, 657 тег не отображается:

SVN Revision Graph

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

ответ

0

Вы заметили, что у вас есть 3 различных кодов SHA1 для каждого тега, которые заключаются в следующем: 07d524b93e8fc6957d06f687f83db0ba897890a9 ссылки/пультов ДУ/метки/657_RemoveTravellogProgressbar ee48ab8efa3f4ed5f54d0d1a3dd8fac76205ab9e ссылки/пультов ДУ/теги/657_RemoveTravellogProgressbar @ 327 23eccb461e341a2f7bd0af03159c61600c888e7c refs/remotes/tags/657_RemoveTravellogProgressbar @ 657

Для получения информации о том, для чего предназначен SHA1, используйте следующее: (вы, вероятно, найдете ответ)

мерзавец кот-файл -p 23eccb461e341a2f7bd0af03159c61600c888e7c

или

мерзавец кот-файл -p ee48ab8efa3f4ed5f54d0d1a3dd8fac76205ab9e

+0

ee48ab8efa3f4ed5f54d0d1a3dd8fac76205ab9e дает обязательство, соответствующий SVN # 327 (как я ожидал - он перечислен в работах/remotes/tags/657_RemoveTravellogProgressbar @ 327) и т. д. Я все еще не уверен, как я могу использовать это, чтобы определить, почему это происходит (только для этих двух тегов), хотя ... – Metal450

 Смежные вопросы

  • Нет связанных вопросов^_^