git svn fetch ruft die gleiche Subversion Revision mehrmals für Niederlassungen

Question

Ich sehe git svn fetch wiederholt die gleichen Subversion Revisionen abrufen, wenn es Zweige in meinem Subversion-Repository findet. Wir sind mit dem Standard-Subversion-Repository-Layout mit Top-Level /Stamm,/Tags und/Zweige Verzeichnisse (und das Git-Repository wurde mit 'Git Svn Init-s' erstellt). Die problematischen Zweige sind jedoch oft Kopien aus einem Unterverzeichnis innerhalb der Amtsleitung, statt Stamm.

Die git svn holen Ausgabe typischerweise etwa wie folgt aussieht:

 
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 = 
..... 

Und wir sind wieder in Revision 1. git svn holen dann weiter Revisionen holen, bis er die Revision erreicht, das den Zweig geschaffen.

Was mache ich falsch? Gibt es überhaupt für mich zu sagen, git svn fetch zu nicht Revisionen abrufen, die es bereits gezogen hat?

Answer 1

Ich bemerkte, diese Frage, weil ich die gleiche Fehlermeldung bekam:

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

Es stellte sich heraus, dass .git/config doppelte Zeilen hatte, die scheinen git-svn, wie diese zu verwirren:

[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/* 

Das Entfernen dieser Duplikate löste merkwürdiges git-svn-Verhalten für mich und könnte auch für Sie. Ich bin nicht sicher, was git-svn veranlasst hat, diese Information überhaupt zu duplizieren. Ich tötete und fuhr den ersten Klon fort, das könnte verwandt sein?

Answer 2

git-svn scheint wiederholt die gleichen Revisionen zu ziehen, weil Sie Tags in Ihrem SVN-Repository haben. Das SVN-Konzept eines Tags unterscheidet sich geringfügig von Git: SVN tags are actually branches (also SVN tags are copies).

Nehmen Sie einen näheren Blick auf Ihre Ausgabe:

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)

Obwohl die Revision r1 = allzu vertraut aussieht, der Rest des Textes wahrscheinlich abweicht. Der Tag-Name (in diesem Fall QuoteSvcFix442@2698) wird mindestens nicht identisch sein.

Ich denke, der einzige Weg, dies zu verhindern ist, indem git-svn die SVN-Tags überspringen. Wenn Sie ohne die Tags nicht leben können, können Sie auch convert the SVN 'tag' branches to real git tags (aber Sie haben alle Tag-Zweige zu holen, zuerst!)

---

Eine verwandte Frage SO mit möglichen Abhilfen: Can Git-svn be used on large, branched repositories?

Einige Diskussion über dieses Problem: git-svn --tags should at least /try/ to handle tags as tags.

Answer 3

Das Entfernen von Duplikaten verursachte immer noch ein Problem für mich. Jedes Mal, wenn Sie den Klonbefehl erneut ausführen, z. git svn Klon svn: //.../svnroot --no-metadata -A authors-transform.txt --stdlayout. Es fügt zwei weitere Zeilen hinzu.Git/Konfig. Ich hatte alle Linien zu entfernen, enthält Zweige = branches/: refs/remotes/ und tags = Tags/: refs/remotes/tags/

Config Weggehen wie unten suchen:

[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 4

Wenn zu irgendeinem Zeitpunkt der Stamm Ihres Repositorys an einer anderen Position in SVN vorhanden war, versuchen Sie, diesen Speicherort anzugeben, um zusätzlich in die Konfigurationsdatei des Repositorys zu gelangen. Zum Beispiel:

[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 
    ... 

Für das Projekt war ich den Import gab es viele Zweige und Tags, die von diesen bisherigen Standorten erstellt worden war. Da es sich um Zweige handelte, die von einem "unbekannten" Ort aus erstellt wurden, warf Git svn die Hände hoch und holte einfach die ganze Geschichte, um es herauszufinden. (Dieser Ansatz erforderte immer noch einen vollständigen Abruf für jeden Standort, aber das war VIEL schneller als ein vollständiger Protokollabruf für jedes Tag)