Wie vermeide ich git-svn und svn CRLF Probleme wie diese?

Question

Ich benutze Git Svn und heute lief ich in Schwierigkeiten.

Ich habe eine git svn clone und arbeitete an meinem Projekt für eine Weile. Nach ein paar Tagen habe ich meine Arbeit auf die svn remote geschoben (git svn dcommit). Dann habe ich versucht, das Projekt mit TortoiseSVN auszuchecken und zu sehen, ob alles in Ordnung ist. Leider wurde alles in Unix-Zeilenendungen konvertiert und VC6 konnte das Projekt nicht öffnen.

Also, mein Git Arbeit Kopie war CRLF, aber meine Svn Arbeitskopie war LF. Ich nehme an, git konvertiert es entweder während git commit oder git svn dcommit.

Darf ich annehmen, dass ich all diese Probleme vermeiden kann, wenn ich core.autocrlf = false für meine git Arbeitskopie einstelle? Wird diese Kraft die Newlines in Ruhe lassen? Gibt es noch etwas, das getan werden muss, um git svn einfach zu benutzen, ohne dass es Probleme für meine Mitarbeiter gibt?

(Es kann auch interessant sein, zu erwähnen, dass ich git svn vor auf der gleichen Maschine verwendet haben, ohne die Einstellungen zu berühren, und das war das erste Mal so etwas passiert.)

Answer 1

Subversion hat eine Möglichkeit, EOL-Konvertierungseinstellungen für die einzelnen Dateien. Und tatsächlich hat Git es auch in Form von .gitattributes-Dateien ('text' und 'eol' Attribute). Für den allgemeinen Fall ist core.autocrlf nicht genug.

Wenn Sie es auf false setzen, haben alle Dateien mit svn: eol-style = native eine LF-Zeilenendung in git-svn Arbeitskopie, die für Windows nicht erwartet wird.

Wenn Sie es auf "True" setzen, werden alle Zeilenenden in LFs konvertiert und in Form von LFs (immer) an SVN gesendet.

Eigentlich sollte svn:eol-style=unset entsprechen '-Text' GIT-Attribut (das bedeutet keine Umwandlung), svn:eol-style=LF --- zu 'EOL = lf' Attribut und svn:eol-style=CRLF --- zu 'EOL = crlf' Attribut; svn:eol-style=native ist systemabhängig, kann also durch eine nicht versionierte eol-Einstellung gesteuert werden, daher ist das entsprechende git-Attribut '! Eol' (das würde bedeuten, dass EOL-Einstellung von core.eol von .git/config erhalten wird).

Anstelle von git-svn können Sie eine beliebige Lösung verwenden, die svn: eol-style automatisch in die entsprechenden .gitattibruest-Werte für einzelne Dateien und umgekehrt konvertiert. Eine Lösung ist die serverseitige: Sie SubGit in der SVN-Repository installieren und nur reine Git-Schnittstelle verwenden, die SubGit schaffen:

$ subgit install path/to/svn/repository 
# Git interface with correct .gtattributes repository will appear at path/to/svn/repository/.git 
# you should setup an access to it 

Dann auf dem Client Sie es und setzt core.eol zu ‚crlf‘ klonen für Windows und "lf" für andere Betriebssysteme (Standardwert ist 'lf').

$ git clone <URL> working_tree 
$ cd working_tree 
$ git config core.eol crlf #for Windows only 

Und danach wird Git in der gleichen Weise wie SVN verhalten.

Alternativ können Sie auf der Clientseite SmartGit verwenden: Sie können das SVN-Repository damit klonen (nicht das vorhandene git-svn-Repository öffnen) --- und dann svn: eol-style in .gitattributes konvertieren. In diesem Fall ist keine zusätzliche core.eol-Einstellung erforderlich, SmartGit kümmert sich darum.