Possono diversi cloni git-svn dello stesso repository svn si aspettano di essere in grado di condividere i cambiamenti quindi git svn dcommit?

Question

Ho letto una grande quantità di "passare da SVN a Git" ed altri articoli "del flusso di lavoro git-svn" sul web, e ancora penso che spesso affrontare situazioni eccessivamente semplici. Essi sono spesso rivolte a ragazzi che vogliono solo usare git e incidere a livello locale, senza utilizzare tutta la potenza di git, come tirare, prendere, unire e simili tra più sviluppatori che sarebbero tutti hanno clonato il repository svn con git-svn, poi ancora aspettano di essere in grado di spingere i loro cambiamenti in qualsiasi momento al repository (ufficiale) svn, e tornare a lavorare in git e condividendo la loro roba, ecc.

Ogni volta che questi articoli ammettere che non si può fare tutto ciò che ci fa in puro git, le conseguenze e le possibili vite up sono mai chiaramente spiegate (o forse è solo a me?). Anche la pagina man git-svn cita avvertimenti, ma non proprio in maniera estensiva.

In base a quello che ho letto, mi sembra che ci potrebbero essere problemi quando git-svn è usato in quel modo specifico, che descriverò di seguito. Qualcuno può dirmi se ho ragione di questo?

Ecco il "voluto" modo di fare le cose:

1. Abbiamo un progetto in un repository svn
2. Developer A git-svn-clone è il repo svn. Egli comincia a incidere le cose a livello locale
3. Developer B git-svn-clone è lo stesso repository svn. Egli comincia a incidere le cose da solo.
4. Dopo aver fatto che da qualche tempo, forse l'aggiunta di devs C / D / ..., e avendo altri sviluppatori che fanno svn "standard" si impegna a repo originale, gli utenti git vorrebbe condividere il loro codice e fare tutti i tipi di magia git.
5. Ogni uno di quegli utenti git vorrebbe essere in grado di spingere l'ora fusa modifiche svn (dcommit?)

La mia domanda è: sto sognando? Ho letto qualche tempo fa, in un libro git credo, che git-svn-clone potrebbe creare repository git che sono, naturalmente, un "specchio" del repo svn, ma che i pronti contro termine Git creato in questo modo da diversi sviluppatori avrebbe diversa " id" e commit avrebbero diverse hash. Quindi la mia comprensione è che questi repo git non avrebbero condividono alcun antenato comune git, e quindi non sarebbe in grado di utilizzare tutti i comandi git è necessario condividere, unire, e così via. E 'vero, stiamo andando ad affrontare i problemi con questo flusso di lavoro?

A volte ho letto questo potrebbe essere fatto, utilizzando almeno un repository "ufficiale" a nudo git, che sarebbe l'unico ad essere git-svn-clonato, e tutti gli utenti git avrebbe dovuto iniziare a forma di questo. Allora avete bisogno di qualcuno che si occupa di questo repo git centrale, e raccoglie le modifiche tra gli sviluppatori git, prima di tutto per dcommiting il repo svn. Questo sarebbe l'unico modo per gli utenti git di essere "a conoscenza" che il repo git originale viene da svn, e avrebbe lasciato li usano tutti i comandi git come gli pare. L'unica persona che avrebbe bisogno di essere fluente in git e svn (e conoscere avvertimenti git-svn) sarebbe il "merge manager" (o qualsiasi altra cosa si chiama).

Sono Sono completamente d'incomprensione avvertimenti git-svn? C'è un modo semplice di fare questo?

Answer 1

Il problema è il passaggio 4, naturalmente. Un dcommit cerca di riprodurre la storia locale al server. Dcommit finge che sei un client SVN. Ora, se il codice che stai dcommitting non è solo da voi, che è qualcosa che è difficile da dcommit a SVN.

Ecco quello che il guru scrive al riguardo:

  

  
• Per ragioni di semplicità e interoperabilità con SVN, è   raccomandato che tutti gli utenti git-svn   clone, prendere e dcommit direttamente da   il server SVN (il telecomando SVN   repository che è), e di evitare tutti   git-clone / tirare / unire / spingere operazioni   tra repository git e rami   che sono o recuperati tramite git svn   clone e che vengono utilizzati anche per spingere   di modifiche indietro nella SVN remoto   repository.
  
• Il metodo consigliato di scambio di codice tra rami Git   e gli utenti è git format-patch e git   Sono, o semplicemente git svn dcommit al SVN   repository.
  
• Dal git svn dcommit utilizza git svn rebase internamente, eventuali rami Git siamo   git push per prima di git svn dcommit su   li richiederanno forzando una sovrascrittura   della ref esistente sul telecomando   repository. Questo è generalmente   considerata cattiva pratica, vedere il   documentazione git-push per i dettagli.
  
• Esecuzione merge git o git pull non è raccomandato su un ramo abbiamo in programma di   git svn dcommit da. SVN non lo fa   rappresentare fusioni in qualsiasi ragionevole o   utile di moda così gli utenti che utilizzano SVN   Se non vedi nessuna unioni che abbiamo fatto.   Inoltre, se si git merge o git   estrarre da un ramo git che è un   specchio di un ramo, svn git   dcommit può impegnarsi a torto   ramo.
  
• git clone non clone rami sotto il refs / telecomandi / gerarchia o   qualsiasi git-svn metadati, o config. Così   repository creato e gestito con   utilizzando git-svn dovrebbe usare rsync   per la clonazione, se la clonazione si deve fare   a tutti.
  
• Non dovremmo utilizzare l'opzione --amend di git commit su un cambiamento che   hanno già dcommitted. È   considerata cattiva pratica a --amend   impegna abbiamo già spinto a una   repository remoto per altri utenti, e   dcommit con SVN è analogo a quello.   Ulteriori informazioni su questo si possono trovare   a modificare un singolo commit e    con riscrivere la storia .
  

Answer 2

Ho avuto modo di sperimentare molto con questo ultimamente, e che sono riuscito a trovare una messa a punto che funziona un po '. Sì, è un rigoroso regime di rebase-solo, sì è complicato, ma ottieni utilizzare Git per lavorare a livello locale (velocità, storia, nascondiglio, indice, ecc).

È possibile utilizzare rami dietro le quinte quando si collabora con altri utenti Git nella tua squadra credo, ma non si è personalmente sperimentato troppo con questo. Finché si linearizzare il log prima dcommitting dovrebbe funzionare.

Ecco la versione corta (ripete molto ciò che è stato già detto):

1. Clonare il repo Subversion in un "recupero" pronti contro termine su un server centrale
2. Init un pronti contro termine "bare" sullo stesso server
3. Push dal repo fecthing al repo nuda
4. Sono gli sviluppatori di clonare il repo nuda e poi
   5. git svn init svnurl per configurare il telecomando git-svn, e
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master così git-svn ha un puntatore a una revisione
5. Automaticamente (commit hook) hanno il "recupero" svn rebase repo, e spingere verso il repository nudo
6. Gli sviluppatori tirare dal repo nudo con git pull --rebase
7. Gli sviluppatori git svn dcommit esecuzione prima deve ripetere l'update-ref sopra in caso di revisioni più recenti provenienti da SVN.

C'è un illustrazione del flusso di lavoro in questa pagina (ho bisogno di più punti reputazione prima di poter inline l'immagine). Aggiornamento: Qui andiamo:

Answer 3

Quello che ho usato per fare, è creare un clone git svn iniziale, poi condiviso ha .git tra gli sviluppatori che utilizzano git, così abbiamo avuto esattamente gli stessi riferimenti.
Tutto sembrava funzionare correttamente come siamo stati in grado di usare "caratteristiche specifiche Git" tra gli utenti git, finché siamo stati in un albero lineare (cioè rebasing invece di fondere).

Answer 4

Non appena entrerete in circolazione "distribuita", si sta meglio con una sola nuda repo git clonato tra gli sviluppatori.
Per quanto riguarda la fase di import-export per il repo SVN pubblico, per altri di utilizzare, gli script
git2svn e svn2git può aiutare incapsulare la magia.

Altre considerazioni quando si lavora in Git e SVN pronti contro termine si trovano nella domanda " Flusso di lavoro e aiutare con git, 2 progetti svn e un singolo “workcopy” "

Answer 5

C'è uno strumento che risolve il problema di condividere repository Git sincronizzato con repository Subversion.

SubGit è un Git-SVN bidirezionale specchietto sul lato server.

Si può installare SubGit in repository Subversion e ottenere repository Git sincronizzato automaticamente con SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit installa pre-commit e post-commit ganci in repository Subversion, pre-ricevere e post-ricezione ganci in repository Git. Come risultato si traduce immediatamente modifiche in arrivo da SVN e Git lati. Dopo gli sviluppatori di installazione SubGit possono utilizzare qualsiasi client Git per clonare e lavorare con repository Git.

SubGit non si basa su git-svn, si utilizza il proprio motore di traduzione nostro team ha sviluppato. Maggiori dettagli su questo si possono trovare in SubGit vs. git-svn confronto. Caratteristiche generali degli SubGit è disponibile qui .

La versione 1.0 SubGit deve accesso locale al repository Subversion, cioè SVN e archivi Git devono risiedere sullo stesso host. Ma con la versione 2.0 che andremo a introdurre modalità proxy Git, quando Subversion e Git repository possono essere localizzati ovunque e solo repository Git hanno SubGit installato in loro, vale a dire i repository Subversion restano invariati.

SubGit è un prodotto commerciale. E 'gratuito per open-source, progetto accademico e anche per i progetti con un massimo di 10 committer.

Disclaimer: io sono uno degli sviluppatori SubGit

.

Answer 6

questo post blog che suggerisce mantenendo un ramo separato per la sincronizzazione con il repository Subversion, in modo tale che sarà ancora possibile fare push / pull nel ramo principale.

Answer 7

Uno dei problemi che ho percepire con git-svn è che memorizza il git-svn-id nel messaggio di commit; perché questo riscrive che commettono, cambia è SHA1, quindi non si può spingere ovunque la gente sarà la condivisione di esso.

Io in realtà preferisco bzr-svn perché invece memorizza il revid bzr nella revisione SVN remota utilizzando le proprietà di revisione SVN funzione invece che significa che nessuna riscrittura revisione locale. Essa ha anche desiderato la proprietà, che due tira indipendenti dello stesso ramo SVN comporterà rami bzr identici e interoperabili.