2010-04-17 7 views
7

Utilizzo SVN da molto tempo e ora stiamo provando su Git. Non sto parlando del dibattito centralizzato/decentralizzato qui. La mia unica preoccupazione è la velocità.Esiste un controllo di versione centralizzato più veloce rispetto a SVN?

Quest'ultimo strumento è molto più veloce. Ma a volte, ho bisogno di lavorare con un approccio centralizzato, che è molto più semplice e meno complesso di quello decentralizzato. La curva di apprendimento è molto veloce, il che consente di risparmiare un sacco di tempo (mentre scavare in un ambiente decentralizzato porterebbe a una perdita di tempo, dato che la curva di apprendimento è molto più lunga e incontriamo più problemi quando si lavora con esso).

Tuttavia, SVN è molto lento rispetto a GIT e non penso che abbia nulla a che fare con l'argomento centralizzato. I sistemi decentralizzati devono anche gestire le connessioni al server e il trasferimento dei file. Quindi posso immaginare che potrebbe esistere un'implementazione più veloce del controllo della versione centralizzata.

Qualcuno ha qualche indizio su questo?

risposta

5

Quello CVCS (centralizzato Version Control System) So di essere molto più veloce di SVN non è un freeware uno:

Perforce

I dettagli Perforce in questo SO answer.

Perforce diagram

Si può vedere un comparison between Perforce and Subversion in this document.
Il supporto per l'unione, in particolare, è molto più efficace.

+0

Interamente concordato sul fatto che p4 è molto più veloce. Come svantaggio, tuttavia, trovo che la sua facilità d'uso sia gravemente carente; al lavoro, abbiamo sviluppatori che usano git-p4 come un problema di riduzione del dolore. –

+0

Beh, questo non mi farà usare (è commerciale: p), ma questo conferma davvero la mia curiosità ed era esattamente il tipo di risposta che stavo aspettando. Non conoscevo questo strumento, grazie. Sembra piattaforma-complient (Win/Max/Linux) e si integra all'interno dell'esploratore di ciascuno di questi sistemi operativi. Molto interessante! :) – Savageman

0

Git è molto flessibile e funziona perfettamente in una disposizione centralizzata. Su un server da qualche parte, creare un repository "nuda" con qualcosa di simile:

mkdir repo 
cd repo 
git init --bare --shared 

Poi spingere il repository nella nuda quella sul server, e chiamare quella repo "centrale".

+1

Ciò non risolve il problema di complessità. Con SVN non puoi sbagliare. Le persone hanno solo bisogno di conoscere 3 comandi: checkout (lo usano solo una volta), commit e update. Funziona e basta. L'unica cosa che puoi sbagliare è dimenticare di aggiornare ... Git è molto più complesso e l'opportunità di rovinare qualcosa è semplicemente troppo alta.Non esiste una sincronizzazione automatica tra locale e remoto. E se qualcosa può sbagliare, lo farà. – Savageman

+1

@Savageman: Spero di non venire qui come un elitismo terribile, ma IMO se i programmatori non sono abbastanza intelligenti da usare un sistema come Git senza incasinare qualcosa, allora mi chiedo se sono abbastanza intelligenti da armeggiare con il software . –

+0

@ Savageman - Per inciso, non tutti i DSCM hanno una curva di apprendimento tanto ripida quanto git; è un po 'unico in termini di quanto solo i suoi interni devono essere capiti solo per leggere la documentazione di comando. Per non dire che non ci sono vantaggi a questo approccio - ma è un po 'di bocciatura in un primo momento. –

1

Git supporta molte topologie, incluso l'approccio centralizzato CVS/SVN. Ci sono diverse opzioni:

  1. Fornire un repository centrale condiviso tramite ssh. gitosis rende tutto più semplice.
  2. Utilizzare account privati ​​github.
  3. Utilizzare il prodotto server commerciale di github, github:fi nel proprio centro dati.
+0

Beh, immagino che non avrei dovuto dare l'esempio Git. Immagina di dover spiegare come utilizzare questo tipo di strumento per le persone che conoscono solo Microsoft Word e how-to google search. – Savageman

+1

@ Savageman, Marcelo - dal momento che stiamo uscendo dall'argomento del controllo di revisione centralizzato più veloce (per il quale Perforce è effettivamente lo strumento ampiamente accettato), penso che bzr sia un'opzione migliore di git nel fare questo tipo di argomento, almeno per gente che cerca un'esperienza utente amichevole per i principianti - può essere utilizzata esattamente nello stesso modo di svn (checkout/update/commit) * o * in una modalità completamente distribuita (clone/push/pull/etc). Git * può * essere utilizzato con qualsiasi flusso di lavoro, ma certamente si sente un po 'supponente riguardo a quale è stato progettato e non fornisce i comandi alternativi specifici del flusso di lavoro. –

+0

Per quanto riguarda ciò che hai detto, penso che bzr possa essere una buona soluzione qui. La domanda è: è davvero più veloce di SVN? Bzr deve essere considerato uno dei DCVS più lenti qui fuori (git, hg). – Savageman

1

Ciò che rende SVN lento è come gestisce le copie di lavoro. Migliaia di file sono toccati e scritti.

Si può provare Bazaar (bzr) perché supporta i flussi di lavoro (ma non so se è molto più veloce) o attendere SVN 1.7 con WC-NG e metadati centralizzati. SVN 1.7 è pianificato per questa estate, ma potrebbe anche essere completato in seguito.

Problemi correlati