git svn fetch несколько раз получает одну и ту же версию Subversion для веток

Question

Я вижу, как git svn fetch многократно извлекает ту же Subversion исправления, когда он находит ветки в моем хранилище Subversion. Мы используя стандартную схему хранилища Subversion, с верхним уровнем каталоги / trunk, / tags и / branch (а хранилище git было созданный с помощью 'git svn init -s'). Тем не менее, проблемные ветви часто копии, сделанные из подкаталога внутри транка, вместо Ствол.

Вывод git svn fetch обычно выглядит примерно так:

r2537 = d5b22e956157af036d4112e42e8fb927e45758c8 (trunk)
        M       Enterprise/VC/libgc/SymbolVenue.cpp
r2538 = cfed4ca0491da0b732f32bfff72ba678450a0915 (trunk)
Found possible branch point: http://repo/prod_repos/trunk/Enterprise/VC => http://repo/prod_repos/branches/file_conversion, 2523
W: Refspec glob conflict (ref: refs/remotes/scripter@832):
expected path: branches/scripter@832
    real path: trunk/Enterprise/Python
Continuing ahead with trunk/Enterprise/Python
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: branches/trunk
    real path: trunk
Continuing ahead with trunk
Initializing parent: file_conversion@2523
        A       gc/QuoteService.cpp
        A       gc/TestSuite.h
        A       gc/quote_svc.pro
        A       gc/QuoteService.h
.....

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)
        D       gc/FixMessageLogger.h
.....
r5 =
r19 =
r20 = 
.....

И мы вернулись к ревизии 1. git svn fetch затем продолжает получать ревизии, пока не достигнет ревизии, создал ветку.

Что я делаю не так? Могу ли я сказать git svn fetch не восстановить ревизии, которые он уже вытащил?

Answer 1

Я заметил этот вопрос, потому что я получил то же сообщение об ошибке:

W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: branches/trunk
    real path: trunk

Оказалось, что .git / config имеет повторяющиеся строки, которые, кажется, путают git-svn, например:

[svn-remote "svn"]
...
    branches = project/branches/*:refs/remotes/*
    tags = project/tags/*:refs/remotes/tags/*
    branches = project/branches/*:refs/remotes/*
    tags = project/tags/*:refs/remotes/tags/*

Удаление этих дубликатов решило странное поведение git-svn для меня, а может и для вас. Я не уверен, что заставило git-svn дублировать эту информацию. Я убил и продолжил первоначальный клон, это может быть связано?

Answer 2

Удаление дубликатов все еще создавало проблему для меня. Каждый раз, когда вы запускаете команду клонирования, например, git svn clone svn: //.../svnroot --no-metadata -A авторы-transform.txt --stdlayout. Добавляет еще две строки в .git / config. Мне пришлось удалить все строки, содержащие branch = branch / : refs / remotes / и tags = tags / : refs / remotes / tags /

Выход из конфигурации выглядит следующим образом:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[svn-remote "svn"]
        noMetadata = 1
        url = svn://.../svnroot
        fetch = trunk:refs/remotes/trunk
[svn]
        authorsfile = /home/users/denn/authors-transform.txt
~

Answer 3

Если в какой-то момент ствол вашего репозитория существовал в другом месте в SVN, попробуйте указать это местоположение для дополнительной загрузки в файл конфигурации репозитория. Например:

[svn-remote "svn"]
... 
    fetch = project/trunk:refs/remotes/origin/trunk
    fetch = previous/location/of/trunk:refs/remotes/origin/trunk-old1
    fetch = another/location/of/trunk:refs/remotes/origin/trunk-old2
    ...

Для проекта, который я импортировал, было много веток и тегов, которые были созданы из этих предыдущих мест. Поскольку это были ветки / теги, созданные из «неизвестного» места, git svn вскинула руки и просто извлекла всю историю, чтобы узнать. (Этот подход все еще требовал полной выборки для каждого местоположения, но это было НАМНОГО быстрее, чем полная выборка истории для каждого тега)

Answer 4

git-svn, по-видимому, неоднократно вытягивает одни и те же ревизии, потому что в вашем SVN-хранилище есть теги. Концепция SVN-тега немного отличается от концепции git: Теги SVN на самом деле являются ветвями (при этом SVN-теги копий ).

Присмотритесь к вашему выводу:

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)

Хотя редакция r1 = выглядит слишком знакомой, остальная часть текста, вероятно, отличается. Как минимум, имя тега (в данном случае QuoteSvcFix442@2698) не будет таким же.

Я думаю, что единственный способ предотвратить это - заставить git-svn пропустить SVN-теги. Если вы не можете жить без тегов, вы также можете конвертировать SVN-теги переходы к реальным тегам git (но сначала нужно получить все ветви тегов!)

---

Соответствующий вопрос SO с возможными обходными путями: Можно ли использовать Git-svn в больших разветвленных репозиториях?

Некоторое обсуждение этой проблемы: git-svn --tags должен как минимум / try / обрабатывать теги как теги .