Ragioni specifiche per l'utilizzo di Subversion? [chiuso]

22

Voglio scegliere un sistema di controllo della versione per la mia azienda. Finora so di avere Git, Subversion e Mercurial.

In questi giorni vedo che Git è il più usato, quindi mi chiedo: ci sarebbe un motivo specifico per usare ancora Subversion o dovrei andare direttamente a Git?

version-control git svn

— user1179459
fonte

36

Entrambi funzionano. L'importante è se soddisfano le tue esigenze, cosa che non ci hai detto.

— Matthew Flynn,

6

Vedi Perché usare SVN? Qualche professionista nascosto (oltre GIT / Mercurial / Bazaar) lì? su Stack Overflow.

— detly

11

Su quale argomento escludi Mercurial?

— mouviciel,

8

-1 per la formulazione soggettiva (baiting IMHO) e "Quei giorni vedo che Git è il più usato" - citazione necessaria. Git è estremamente comune nel mondo open source, ma nello spazio aziendale è molto più raro. Ai corpi piace molto l'idea di un repository unico, centrale e autorevole e sono molto lenti a cambiare. Nello spazio aziendale è più probabile che tu veda un buon CVS anche di SVN, non importa un DVCS.

— Keith,

4

@RobinWinslow - SVN è diverso da Git. Più adatto ad alcune circostanze e peggio ad altre. Personalmente preferisco DVCS in generale e ovviamente preferisci Git, ma entrambi sono opinioni soggettive. Non sono privi di valore, ma non appartengono a un sito come questo.

— Keith,

46

SVN non è affatto morto. È ancora ampiamente utilizzato e presto non andrà da nessuna parte. SVN è molto più semplice da utilizzare rispetto al controllo della versione distribuita, soprattutto se non si esegue effettivamente un progetto distribuito che necessita del controllo della versione distribuita.

Se hai solo un repository centrale (che è tutto ciò di cui la tua azienda avrà bisogno se sono ancora abbastanza piccoli da farcela senza controllo del codice sorgente), è molto più semplice usare SVN per interagire con esso. Ad esempio, con SVN è possibile estrarre le modifiche dal repository o eseguire il commit delle modifiche locali su di esso, con un'unica operazione, mentre HG e Git richiedono due o tre passaggi per eseguire il lavoro equivalente.

E con le recenti revisioni, SVN ha risolto molti dei problemi di prestazioni che hanno fatto sì che le persone preferissero HG e Git. È significativamente più veloce di quanto non fosse un paio d'anni fa e, a questo punto, non c'è davvero alcuna buona ragione per guardare HG o Git per il tuo progetto a meno che tu non abbia effettivamente bisogno delle funzionalità avanzate del controllo della versione distribuita.

— Mason Wheeler
fonte

16

Non sono completamente d'accordo con la tua stima, ma vorrei aggiungere un punto importante a favore di SVN: molte persone del settore sono a proprio agio con SVN ma non conoscono abbastanza Git per lavorarci comodamente. Se tutto il tuo team è abituato a SVN, passare a Git potrebbe avere un costo piuttosto alto. (Il contrario può anche essere vero, ovviamente).

— Joachim Sauer,

8

Vorrei votare questa dozzina di volte se potessi. Molte persone vanno con la moda, ma non pensano davvero perché avrebbero bisogno del controllo del codice sorgente distribuito.

— Euforico,

21

@Euforico: so esattamente perché voglio sempre il controllo del codice sorgente distribuito su ogni progetto. Ha l'importante effetto collaterale di rendere la ramificazione e la fusione semplici, ovvie e affidabili. Subversion è ancora impantanato in casi angolari con ramificazione perché il modello base che ha scelto lo rende semplicemente più complicato.

— Jan Hudec,

18

Il controllo della versione distribuita non è una "mania". È un'evoluzione del controllo del codice sorgente, proprio come il controllo della versione simultanea era un'evoluzione del paradigma del blocco dei file.

— JesperE,

6

@MichaelBorgwardt, in realtà l'ho fatto un numero di volte. È molto più facile che con la sovversione, il fatto che tutto sia locale aiuta molto, non è necessario spiegare l'interazione "client" e "server". Il flusso di lavoro in git o hg è molto più naturale e intuitivo (se stai lontano dai bit delicati come l'editing della cronologia).

— SK-logic,

19

Gli strumenti client non sono ancora stati menzionati. Puoi certamente fare tutto con uno script da riga di comando ma avere l'integrazione della GUI può essere un vero aumento della produttività.

Lavoriamo principalmente con Visual Studio; l'integrazione nell'IDE è decisamente migliore con SVN che con Git in questo momento. Questo potrebbe cambiare in futuro, ma certamente lo soppeserei nella tua decisione tanto quanto le funzioni di controllo della versione.

Proprio come tutto il resto, un sistema di controllo della versione non è un obiettivo in sé, solo uno strumento per portarti dove stai andando. Scegli quello che ti porterà più velocemente in base alla tua situazione.

— njr101
fonte

Questo è un buon punto. Penso che uno dei motivi per cui le persone preferiscono Git a SVN è che Git ha strumenti CLI migliori. Ma questo può essere compensato con una buona interfaccia grafica di terze parti SVN, come TortoiseSVN su Windows.

— Euforico,

2

Questo è uno dei motivi per cui abbiamo scelto Mercurial (e TortoiseHg) su Git. I vantaggi della distribuita controllo di versione e attrezzature decente e l'integrazione IDE.

— HappyCat,

15

Sono un fan di Git. Di recente ho dovuto ammettere che uno degli aspetti negativi di Git è che identifica le versioni con hash come opposte ai numeri di versione di svn. Il numero di rilascio può essere più facilmente trasmesso per telefono o qualcosa del genere.

E questo è l'unico pro che posso immaginare. Se vuoi davvero fare affidamento su quella funzione, puoi averla in un VCS Bazaar distribuito e / o centralizzato . In Git ci sono tag che possono servire allo scopo.

Ad ogni modo, non riuscivo a immaginare di svilupparmi senza un rapido cambio di diramazione e una scorta. Queste due caratteristiche da sole battono SVN, dove per quanto mi ricordo lo stesso compito richiesto la creazione e il checkout di un intero albero in directory separate per raggiungere lo stesso obiettivo.

Quelle cosiddette "funzionalità avanzate di controllo della versione distribuita" arrivano con il tempo e non è necessario impararle all'inizio. Non aver paura di loro. Sono qui per aiutarti, non per metterti in mezzo. E non ci sono problemi per impostare un repository centrale per un DVCS.

— Rajish
fonte

1

Questo in realtà è discutibile, git ha bisogno solo di una parte abbastanza grande dell'hash per essere in grado di disambiguare, di solito è sufficiente qualcosa di ~ 6 caratteri, non l'intero hash.

— TC1,

2

In pratica, non si passa mai l'hash git. È possibile utilizzare qualsiasi prefisso univoco dell'hash, che in genere è 6-7 caratteri.

— JesperE,

1

@JesperE: Sì, ma i numeri delle versioni SVN aumentano in sequenza nel tempo, mentre gli hash di Git, anche se li abbrevia, potrebbero anche essere casuali.

— Keith Thompson,

2

Con SVN puoi facilmente estrarre parti di un repository fino al livello della cartella, mentre con git ottieni l'intero repository, inclusa tutta la cronologia.

A seconda della situazione, ciò può comportare alcuni vantaggi per SVN

(questo ha anche alcuni grandi svantaggi come la spazzatura nascosta ".svn" fino all'albero delle cartelle).

— Richard Nichols
fonte

3

nota: no .svn garbage from v1.7 - ora è tutto archiviato in un'unica posizione.

— gbjbaanb,

Questo non è corretto - git consente di estrarre solo i file, senza la cronologia, ed è anche possibile estrarre solo parti del repository - singoli file se lo si desidera. È un po 'più complesso di svn, ma la capacità è lì.

— Benubird,

2

"Se hai un'attività che può essere eseguita in sei ore, è meglio scrivere uno strumento che lo fa in 20 minuti, anche quando la creazione dello strumento richiede sei ore?"

Il controllo della versione distribuita è una bestia diversa da affrontare. Richiede un apprendimento sostanziale per ogni sviluppatore. Se si dispone del buffer per supportare il processo di apprendimento per ogni sviluppatore, è necessario passare a un buon sistema di controllo della versione distribuita. Terminata la fase di apprendimento, il controllo della versione distribuita è molto meglio del controllo centralizzato della versione.

Il controllo della versione distribuita sembra essere un'eventualità. È qui per rimanere per molto tempo, è meglio che ci adattiamo prima o poi. Ricordo la stessa discussione quando SVN era nuovo e le persone erano abituate a CVS, molti argomenti furono dati per non usare SVN, ma alla fine SVN divenne il sistema di controllo versione più popolare.

Se la società è ben consolidata con un sacco di codice sorgente nel sistema di controllo della versione esistente, passare a un nuovo sistema è un grosso compito, ma se la società è piccola o si avvia, passare a un nuovo controllo di versione è molto semplice. Ma se ti attieni a un controllo di versione precedente (in una nuova configurazione), colpirai il collo di bottiglia da qualche parte in futuro, dove dovrai comunque pianificare una migrazione del controllo di versione.

Ho visto molti commenti SVN pro, ma tutti tendono ad essere della natura "SVN non è male" piuttosto che "SVN è meglio". Quindi ti consiglio vivamente di scegliere un controllo di versione distribuita (come Git) per il tuo progetto.

EDIT Vantaggi di GIT rispetto a SVN

~~Nessun server dedicato richiesto~~ In realtà, entrambi possono essere utilizzati senza server.
Può continuare lo sviluppo anche senza una connessione di rete.
La gestione delle filiali è molto più semplice.
Migliore supporto da strumenti di CI come Bamboo

Qualcuno ha menzionato gli strumenti (per Visual Studio) come motivo per attenersi a SVN. http://gitscc.codeplex.com/ fornisce supporto GIT per Visual Studio.

— Apeirogon Prime
fonte

6

SVN fa maniglia file binari meglio allora Git o Hg.

— Nome falso

2

"In futuro colpirai il collo di bottiglia da qualche parte in cui dovrai eventualmente pianificare una migrazione di controllo versione ..." Mi dispiace, non posso essere d'accordo sul fatto che questa sia una buona ragione per fare la mossa oggi. Ho lavorato su molti progetti in cui questo approccio porta a rendere le cose più complicate del necessario e il progetto viene annullato molto prima che possa trarre vantaggio da quei benefici futuri. A volte abbastanza buono, è abbastanza buono. Attenersi a YAGNI e prendere ciò che fa il lavoro oggi. In seguito ci sarà abbastanza tempo per preoccuparsi delle migrazioni. Almeno avrai ancora un progetto.

— njr101,

2

Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Non sono completamente d'accordo con questo. Può avere alcuni benefici percepiti in alcune circostanze, ma qualcosa di semplice come il numero di versione in svn che è leggibile dall'uomo è un enorme vantaggio in molte organizzazioni.

— TZHX,

1

@apeirogon - Tutto si riduce a ciò che inserirai nel repository. Il solo HEAD di uno dei principali repository con cui lavoro è 11,1 GB! Se lo avessi in un repository Git / bzr / hg, probabilmente richiederebbe oltre 100 GB.

— Nome falso

1

Ovviamente, questo perché questo particolare repository è pieno di file PCB e modelli 3D, tutti in formato binario e non molto efficienti in termini di spazio. La raccomandazione qui (Electronics.SE, ad esempio per le persone che memorizzano i file di progettazione PCB, ecc.) È molto diversa rispetto a quella per chi memorizza il codice sorgente.

— Nome falso

1

ci sarebbe un motivo specifico per usare Subversion in quei giorni

A parte il supporto degli strumenti negli IDE (che non uso) - non proprio, no. Naturalmente SVN può essere più familiare, ma questo è l'unico motivo, e ho trovato sia Hg che Git molto facili (e molto veloci) da imparare.

Sì, ci sono tutte quelle guide complesse là fuori che descrivono come Git sia banale quando capisci che i rami sono solo endofunctor omeomorfi che mappano le sotto-cartelle di uno spazio di Hilbert. ¹

Non lo capisco. Ma sai una cosa? Non importa Non è necessario conoscere nessuna di queste cose per usare Git.

Per la maggior parte, Git e Hg sono facili da usare e presentano vantaggi definitivi rispetto a SVN. L'elefante nella stanza si sta ovviamente ramificando: i rami funzionano solo in Git e Hg. Al contrario, in SVN sono dolorosi nel migliore dei casi e rotti nel peggiore dei casi (unendo più teste).

Ovviamente puoi ancora usare SVN. Puoi anche usare ancora Windows XP. Tuttavia, la maggior parte degli utenti che hanno provato entrambi concordano sul fatto che una delle alternative sia di gran lunga superiore.

¹ Sì, capisco che questo è uno scherzo. Credo.

— Konrad Rudolph
fonte

Un tutorial Git con endofunctor omeomorfi che mappano le sottomenifold di uno spazio di Hilbert? Devo leggerlo! Ma questo non si applica piuttosto a Darcs, che è scritto in Haskell (a cui mi riferisco endofunctor ) e ispirato dalla meccanica quantistica (da qui lo spazio di Hilbert )? Non riesco davvero a vedere cosa Git e HG hanno a che fare con queste cose.

— leftaroundabout

@leftaroundabout È uno scherzo. La descrizione non è nemmeno accurata (per quanto ne so). È un riff sui molti tutorial che iniziano con "i rami git sono facili quando ti rendi conto che ..." e poi c'è una complessa metafora specifica del dominio dopo di esso.

— Konrad Rudolph,

1

Hai mai pensato che tutti quei tutorial troppo complicati esistano per una ragione? E a cosa serve? Non ho mai capito l'ossessione che la folla di DVCS ha per ramificare e poi reintegrare un ramo per ogni piccola cosa. Mi è sempre sembrata una soluzione alla ricerca di un problema. Reintegrare una filiale in SVN è difficile perché è una cosa davvero stupida e concettualmente sbagliata da fare in primo luogo , e non trovo davvero alcun argomento che si riduce a "il nostro prodotto rende molto più facile fare la cosa sbagliata" molto convincente.

— Mason Wheeler,

1

Per quanto riguarda il lavoro su più modifiche in parallelo, ammetto che è un po 'doloroso, ma la soluzione giusta è lo scaffalatura, che è prevista per la prossima versione di SVN. E la maggior parte delle volte, se stai lavorando su più modifiche contemporaneamente (e soprattutto se lo stai facendo in modo coerente!) Questa è la prova di un problema più ampio che dovrebbe essere affrontato a livello di organizzazione, non abilitato con nuove utensili. (Vedi sopra, ri "il nostro prodotto rende molto più facile fare la cosa sbagliata" e l'articolo classico di Joel sul cambio di attività umana.)

— Mason Wheeler

3

@KonradRudolph L'unione dei rami nel bagagliaio funziona perfettamente nelle ultime versioni di SVN. Sta migliorando costantemente da diversi anni a dove ora è molto buono.

— Adam Bruss,