2010-02-18 20 views
7

I vantaggi dell'uso di git-svn su git sono ovvi (compatibilità con svn), ma quali sono i vantaggi di git su git-svn?Quali sono i vantaggi di git su git-svn?

+5

L'accesso a svn non è un "vantaggio di git-svn su git". Lo scopo di git-svn è di darti i vantaggi di git su svn. Non si può usare utilmente git-svn senza usare git. –

risposta

5

Significa semplicemente che è necessario gestire un VCS in meno nella catena di sviluppo (svn).
In termini di amministrazione:

  • si sono lasciati con i repository distribuiti gestite da Git, ognuno autonomo con la loro storia completa
  • non si dispone di mantenere una connessione ad un repo SVN centrale.
  • è possibile organizzare i backup in modo diverso (spingere i dati in un backup remoto repo nuda, o esportare il repo Git attraverso git bundle)

E naturalmente è possibile gestire tutte le advantages of Git over SVN.

+0

Puoi essere più dettagliato in termini di utilizzo effettivo (cioè velocità, funzionalità)? – Mike

+1

@ Mike: ho completato la mia risposta. – VonC

3

git-svn e git condividono la stessa funzionalità mentre si lavora localmente. La differenza appare quando si inviano o si ricevono modifiche dal repository remoto.

  1. Push vs. dcommit.

    Perché git-svn richiede questo comando separato dcommit?

    Poiché il repository Subversion si comporta in modo diverso dal repository Git remoto: SVN cerca sempre di unire le modifiche in entrata a livello di directory. Se si modifica un file che è stato modificato contemporaneamente da un altro utente, SVN rifiuta le modifiche in arrivo con l'errore non aggiornato. Altrimenti commit/dcommit passaggi.

    Al contrario, Git push restituisce non aggiornato errore quando si modifica lo stesso ramo/tag, indipendentemente dai file che sono stati toccati.

    Come risultato, git-svn dcommit deve assicurarsi che la versione appena impegnata sia la stessa prevista (alcune directory potrebbero essere unite automaticamente durante dcommit). Ciò significa che git-svn recupera/recupera sempre le modifiche appena inviate al repository SVN.

  2. Il file ignora.

    Quando si ignorano determinati file in un albero di lavoro e si esegue questa modifica, non è possibile inviare questa modifica con git-svn dcommit. Quindi, non c'è modo di condividere ignora con altri utenti del repository SVN.

  3. Attributi Git.

    Sia Subversion che Git hanno determinati metadati associati a file e directory. Simile a .gitignore non c'è modo di condividere .gitattributes con i colleghi.

  4. L'unione si esegue.

    Infine, quando si prova a dcommit un commit unione si ha la possibilità che determinati commit non vengano inviati al repository SVN.Ciò accade quando tutti i commit di un ramo unito non sono ancora stati inviati al repository SVN.

La maggior parte di questi problemi git-svn è difficile o addirittura impossibile da risolvere. È possibile considerare SubGit - un'alternativa lato server a git-svn che corregge la maggior parte di essi.

Per ulteriori dettagli, vedere SubGit documentation e SubGit vs. git-svn comparison.

Problemi correlati