2009-07-01 9 views
9

Ho un repository di subversion ospitato su Linux ma accessibile solo via client Windows come è per l'origine di una grande applicazione Windows.Si può fare git-svn per gestire CRLF come client di subversion nativi?

Sarebbe fantastico se potessi lavorare su questo repository usando git-svn (fornito da msysgit).

Ho un po 'di tempo cercando di far sì che il repository non si ritrovi in ​​un inceppamento sulle terminazioni della linea di stile di Windows.

Dopo svn clone una cassa del repository git con:

  • core.autocrlf = true mostra modifiche a qualsiasi file che non utilizzano effettivamente LF nel repository.
  • core.autocrlf = input mostra le modifiche a qualsiasi file che effettivamente utilizza LF nel repository.
  • core.autocrlf = false mostra le modifiche a tutto.

Qual è l'opzione migliore qui? Devo usare core.autocrlf = true e commettere le modifiche da LF a CRLF per i file interessati?

Sono molto vicino a gettare la spugna e mettere la mia copia di lavoro di Subversion in un repository git. Questa sarebbe una soluzione scadente, ma consentirebbe almeno rami e casse locali. Ovviamente diventerà un enorme problema continuare ad aggiungere file quando vengono aggiunti a subversion.

MODIFICA: Per coloro che sono interessati. git-svn è un dolore reale se sei su Windows. La risposta di hasen j qui sotto è probabilmente quella giusta, ma non posso seguire il suo consiglio senza attirare l'ira degli altri sviluppatori nella mia squadra.

essenzialmente sto abbandonando questa domanda poiché non porterà a un risultato ragionevole. Speriamo che il prossimo Google Summer of Code attiri qualcuno che voglia ritirare il proprio progetto "Proper git-svn support on Windows". Vedi http://git.or.cz/gitwiki/SoC2009Ideas#Propergit-svnsupportonWindows

+0

Beh, sono davvero sconcertato. Ho iniziato a provare a sistemarlo di nuovo ma la bassa velocità del clone svn su windows mi ha fatto iniziare a farlo su Linux. Ho portato a repo su Windows poi disabilitato CRLF e fatto un reset --hard. Ora mi sembra di avere un repository git-svn funzionante che si comporta correttamente ... Ora per capire quali passi sono effettivamente necessari per far funzionare tutto questo tempo ... Si spera che questo abbia funzionato davvero e non mi imbatterò in problemi quando comincio usandolo. – toholio

risposta

1

Dal momento che la mia altra risposta non si applica bene a voi, qui è un altro modo per affrontare la situazione:

Usa sia svn e git; nella stessa directory di lavoro.

Lavorerai principalmente con git, prelevando dal repository upstream, apportando modifiche locali, filiali locali, ecc; tutto ciò che fai normalmente quando lavori su un progetto git locale.

Quindi, quando si desidera eseguire il commit sul repository svn centrale, utilizzare il client svn.

Ho avuto un po 'di esperienza in questo, solo che non avrei fatto un svn commit, ma invece di creare una patch con svn diff e inviarlo (dal momento che non avevo accesso di commit in ogni caso).

+0

Questa è una soluzione intelligente. Sperimenterò con questo. – toholio

+0

* insomma, intendevo ovviamente. – toholio

+1

Alla fine ho finito per utilizzare un repository git totalmente locale e fare aggiornamenti (al ramo master di git) e mi impegno al repository remoto usando SVN. Non riesco a ottenere una cronologia locale molto utile, ma ottengo in questo modo i rami delle funzionalità e altre funzionalità.Spero che in futuro avrò un po 'di tempo per provare e correggere cosa c'è di sbagliato in git-svn. – toholio

1

Ho avuto un problema simile. Per risolverlo, dopo il clone git-svn, ho applicato unix2dos a tutti i file perché, nel mio caso, tutti i file nel repository SVN utilizzavano CRLF. Quindi, suppongo che dovresti provare la conversione CRLF-LF manualmente subito dopo git-svn.

+0

Questa sembra essere la mia migliore opzione per ora. Posso usare l'output di "git status" per elencare i file modificati ed eseguirli attraverso uno script per "correggerli". L'impostazione di "core.fileMode = false" e di "git reset --hard" era necessaria per riportare le cose a come avrebbero dovuto essere realmente. Kludgy, ma sembra aver fatto il trucco. – toholio

+0

In realtà, questo sembra ancora sconvolgere il diff di git. Torno al mio piano originale meno attraente di mettere la mia copia di lavoro in un repository git. – toholio

0

Normalmente, che ci si vuole impostare l'opzione core.autocrlf in questo modo:

git config core.autocrlf true 

Ma secondo this article, sembra che non gioca bene con git-svn specifico. Potrebbe valere la pena provare una seconda copia sicura del repository SVN per vedere se funziona.

0

Di solito pulisco il mio clone git-svn con git-filter-branch su recode dos..ascii -f. (Ciò ha anche aiutato per la conversione latin1..utf8.)

+0

Ma questo non distrugge la cronologia delle annotazioni git? Ho un problema simile all'OP, credo, e manualmente "correggere" i file dopo il clone significa solo che sto scrivendo su tutta la cronologia di quei file, rendendolo inutile. – Enno

6

Fatti un favore e non scherzare con le terminazioni di linea, mantienile così com'è. impostare autocrlf a false.

Qualsiasi editor di testo semi-decente in Windows dovrebbe essere in grado di gestire le terminazioni di linea in stile unix.

core.autocrlf = false mostra le modifiche a tutto.

penso che se solo lo fai dopo il fatto, non sarà nulla di buono.

È necessario eliminare questo repository, impostare autocrlf su false e quindi fare il clone.

+0

Purtroppo gli editori mezzi decenti non includono tutti quelli necessari per costruire il progetto. Stupido, ma per ora è un oggetto immobile. Ho sperimentato diverse impostazioni prima del clone, incluso fare il clone su una macchina Linux. Non riuscivo ancora a ottenere le cose in uno stato in cui Git o gli strumenti di costruzione non causavano troppe cose da contrassegnare come modificato quando erano interessate solo le terminazioni di riga. Ti darò un upvote anche se, come sembra che questo potrebbe funzionare per la maggior parte delle persone. – toholio

+0

In tal caso, convertire tutte le terminazioni di riga in CRLF e eseguire il commit nel repository svn principale. – hasen

+0

Apparentemente, non sarà permesso. Sospiro. – toholio

0

Un'altra buona conversations here su core.autocrlf.

+0

Non penso che questo aiuti con il problema git-svn. C'è qualcosa di insignificante dentro di te che fa diventare un checkout utilizzabile da Windows. – toholio