SVN? VSS? Perché uno è migliore dell'altro?

Question

Tendo ad avere la sensazione che la maggior parte della gente qui pensa che SVN sia una bontà d'oro, mentre VSS è il peggior programma mai concepito (almeno per quanto riguarda il controllo della versione).

Detto questo, perché? Ho usato alcuni CVS e il mio attuale lavoro utilizza VSS, e da un grugnito sul punto di vista del team, non posso davvero dire molta differenza. La maggior parte delle differenze che ho visto sono cosmetiche. Certo, non ho provato a fare alcuna ramificazione/fusione in entrambi, ma come un programmatore che entra, controlla i file, lavora su quei file e li controlla alla fine della giornata, perché vorrei 1 su altro?

Answer 1

"Visual SourceSafe? Sarebbe più sicuro stampare tutto il codice, eseguirlo tramite un distruggidocumenti e incendiarlo. " - (Attribuito a un dipendente Microsoft non identificato).

SourceSafe ha molti problemi e nessuna funzionalità di riscatto. Esistono diverse alternative disponibili multipiattaforma che sono più sicure, veloci e potenti. Subversion è probabilmente il più usato di questi. Alcune persone preferiscono sistemi di controllo delle versioni distribuiti come Git, Mercurial o Bazaar.

qualche lettura sul perché VSS è poi così male:

• Visual SourceSafe: Microsoft's Source Destruction System
• Visual SourceSafe Version Control: Unsafe at any Speed?
• (E my own experiences)

Answer 2

Vi rimando alle risposte a What is so great about Subversion?.

Answer 3

Microsoft, che rende Visual Source Safe, non lo utilizza internamente per progetti di qualsiasi dimensione significativa. Questo è un segno importante contro di esso, nel mio libro. E usandolo per progetti di grandi dimensioni, capisci perché; è LENTO e Dio ti aiuta se decidi di lasciarlo automaticamente unire.

Answer 4

VSS ha una storia davvero brutta che deve superare. Le versioni più recenti sembrano essere più stabili, ma ha ancora una tonnellata metrica di bagaglio negativo che circonda.

Answer 5

Il mio ultimo, ma uno-società passati da VSS a causa di SVN

1. espansione. Il numero di programmatori è raddoppiato e non è stato necessario effettuare il fork delle licenze VSS aggiuntive
2. Bug. VSS è in grado di mantenere l'ultima versione di un file, ma le storie spesso sono state danneggiate.
3. Altri bug. Gli strumenti di verifica/recupero erano inutili in quanto hanno iniziato a bloccarsi quando il database diventava molto grande.

Answer 6

SVN ha alcune funzioni importanti su CVS/VSS, come i commit atomici, copie economiche, una memoria più efficiente sul lato server.

SVN, tuttavia, non è l'unico sistema di controllo di revisione là fuori ... Ci sono molte diverse applicazioni di controllo di revisione. Una nuova tendenza sembra essere verso il controllo di revisione distribuito, come Git o Mercurial.

Answer 7

Bene CVS e VSS sono praticamente la stessa cosa per quanto riguarda la funzionalità. Quindi non sono un buon punto di partenza per confrontare ciascuno di essi.

Tuttavia probabilmente non vedrai mai una differenza tra SVN e VSS se li usi come un grugnito della squadra. Devi davvero iniziare a usarli come project manager per vedere davvero le differenze, come ramificazione, unione, ecc.

Answer 8

SVN funziona bene dal punto di vista dello sviluppatore, ma il modo in cui memorizza le informazioni di configurazione su tutto l'albero delle directory è esasperante per gli amministratori di sistema (specialmente quelli incaricati di spostarlo su un altro server quando gli sviluppatori si rifiutano di eseguire un processo di commit/ricontrollo). :) Quindi, non è TUTTA la bontà d'oro!

Answer 9

VSS non è atomic, quindi un massimo durante un grande check-in da un altro utente comporterà un set di file incompleto. Questo peggiora anche se si lavora su una WAN a causa della progettazione di VSS per lavorare su azioni.

Answer 10

In realtà penso che Perforce sia la bontà dell'oro. Gli strumenti della GUI sono abbastanza buoni da poterli dare a un designer o artista e farli usare il controllo del codice sorgente come noi sviluppatori. Sono abbastanza sicuro che la finestra VSS File-> Aggiungi file sia antecedente a Windows 95.L'intero concetto di file in uso è bloccato è assurdo. Non abbiamo risolto decenni fa con il versioning CONCORRENTE? Ho sperimentato la corruzione della storia e (correggimi se sbaglio) ma VSS non supporta nemmeno i rami e le fusioni.

Answer 11

Si dovrebbe correre da VSS non appena possibile. Se non hai avuto problemi con esso in passato, sei dovuto da alcuni. È come una bomba a orologeria della roulette russa: non si sa mai quando soffierà.

SVN è un ottimo strumento e molto facile da configurare, gestire. Gli strumenti di amministrazione per il backup o la replica sono molto carini.

Vorrei raccomandare SVN su VSS ogni giorno.

Answer 12

So che è facile da imparare su VSS, ma è importante ricordare alcune cose (uscire dalle erbacce per un secondo!)

• per i piccoli team di sviluppo Microsoft, VSS è un soluzione molto facile da implementare, dove l'alternativa è NESSUN CONTROLLO VERSIONE.
• VSS non ha costi, non richiede server (diverso da una condivisione file).
• Demoninator comune più basso.
• Generalmente funziona e molti negozi lo usano.
• Preferirei avere VSS come opzione piuttosto che non esistesse.

Non devi essere d'accordo con me su tutti questi punti, sto solo dimostrando che ha il suo posto e ha valore in diversi scenari.

Answer 13

Il vecchio argomento dell'integrazione in Visual Studio non funziona più. AnkhSVN 2.0 fornisce una soluzione integrata e VisualSVN integra TortoiseSVN in Visual Studio.

E TortoiseSVN è già un motivo sufficiente per passare a molti utenti.

Answer 14

Ho problemi con VSS con codice Java. Mentre una getLatestVersion, VSS non è in grado di gestire la struttura nidificata di progetti e pacchetti in java. Ho ottenuto strutture di cartelle inifite per lo stesso. SVN è abbastanza semplice in questo senso.