Git svn fetch возвращает одну и ту же ревизию Subversion несколько раз для ветвей

Я вижу 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/[email protected]):
expected path: branches/[email protected]
    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: [email protected]
        A       gc/QuoteService.cpp
        A       gc/TestSuite.h
        A       gc/quote_svc.pro
        A       gc/QuoteService.h
.....

r1 = d349ed8cb2d76596fe2b83224986275be4600fad ([email protected])
        D       gc/FixMessageLogger.h
.....
r5 =
r19 =
r20 = 
.....

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

Что я делаю неправильно? В любом случае, я должен сказать git svn fetch для не извлекать исправления, которые он уже вытащил?

Ответы

Ответ 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, чтобы дублировать эту информацию в первую очередь. Я убил и продолжил начальный клон, это может быть связано?

Ответ 2

Удаление дубликатов все еще создало проблему для меня. Каждый раз, когда вы повторно запускаете команду клонирования, например. git svn clone svn://.../svnroot --no-metadata -A authors-transform.txt --stdlayout. Он добавляет еще две строки в .git/config. Мне пришлось удалить все строки, содержащие ветки = ветки /: refs/remotes/ и теги = теги /: 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
~

Ответ 3

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

Внимательно посмотрите на свой результат:

r1 = d349ed8cb2d76596fe2b83224986275be4600fad ([email protected])

Хотя версия r1 = выглядит слишком знакомой, остальная часть текста, вероятно, отличается. Как минимум, имя тега (в данном случае [email protected]) не будет одинаковым.

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

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

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

Ответ 4

Если в любой точке соединительная линия вашего репозитория существовала в другом месте в 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 подбрасывал руки и просто извлекал всю историю, чтобы узнать. (Этот подход по-прежнему требовал полной выборки для каждого местоположения, но это было намного быстрее, чем полная выборка истории для каждого тега)