VSS o SVN per un progetto .Net?

Al lavoro, uno dei dirigenti mi ha chiesto di fare una ricerca su quali potrebbero essere i vantaggi di cambiare il server di controllo del codice sorgente corrente (Visual Source Safe) del mio progetto in SVN.

In realtà non ho nulla contro SVN, in realtà mi piace scavare, ma a mio modesto parere, il passaggio a SVN non porterà benefici significativi al progetto e ci costringerà a utilizzare alcuni strumenti di terze parti per gestire il controllo del codice sorgente da Visual Studio (sviluppiamo utilizzando principalmente solo strumenti Microsoft).

Quindi, come primo passo nella mia ricerca, ti chiedo: quali potrebbero essere i vantaggi del passaggio da VSS a SVN?

SVN è più popolare di VSS e ha molti vantaggi. VSS è vecchio e obsoleto.

  • Perché non VSS
  • Visual SourceSafe: Microsoft Source Source Destruction System
  • Controllo del codice sorgente: qualsiasi cosa, ma SourceSafe
  • Controllo della versione di Visual SourceSafe: non sicuro a qualsiasi velocità?

Molti sviluppatori oggi stanno passando da VSS a SVN. Se cerchi “SVN” e “VSS” in Google, ti verranno mostrati molti articoli relativi alla migrazione da VSS a SVN .

  • Il modello lock-modify-unlock di VSS rende la collaborazione sui file in rapida evoluzione un grosso problema. Oltre al sovraccarico di aver bisogno di un amministratore per sbloccare i file che qualcuno ha verificato mentre sono in vacanza.
  • Con VSS, non è questione di perdere dati: è QUANDO. Il tuo repository sorgente dovrebbe essere una pietra: se la workstation di uno sviluppatore si blocca, dovresti aver perso solo le modifiche a HIS. Non dovresti perdere file e dati casuali dal repository
  • La VSS non è stata mantenuta dalla SM in oltre 6 anni. Puoi ancora ottenere supporto per questo?
  • A seconda degli strumenti di backup, potrebbe non essere ansible ottenere un backup completo del repository VSS se è stata registrata una sola persona nel server (nel senso che hanno lasciato gli strumenti dev aperti o hanno lasciato il client VSS in esecuzione).
  • VSS richiede che tutti gli utenti abbiano un controllo quasi completo, a livello di file system (autorizzazioni NTFS), dei file che costituiscono il repository.
  • Non ci sono API buone, utilizzabili e facilmente disponibili per VSS e gli strumenti di terze parti sono per lo più deboli.
  • L’unione fa schifo in VSS.
  • VSS: se gli sviluppatori si sviluppano su più fusi orari, l’atto stesso di entrambi di effettuare il check-in può danneggiare il database se effettuano il check-in troppo ravvicinati, nell’ordine sbagliato.

Ora, questo non vuol dire che Subversion sia impeccabile: ci sono certamente cose che potrebbe fare meglio e cose che non fa affatto. Ma tutte le persone che hanno lavorato con VSS e SVN molto probabilmente non torneranno mai in VSS.


Se scegli SVN. Ecco un elenco di strumenti che potrebbero essere necessari:

  • AnkhSVN è un Subversion SourceControl Provider per Visual Studio.
  • RapidSVN è un client Subversion multipiattaforma.
  • TortoiseSVN è un software di controllo sorgente / SCM facile da usare per Microsoft Windows e forse il miglior client Subversion standalone che ci sia.
  • VisualSVN è un plug-in di Visual Studio che integra Subversion e TortoiseSVN perfettamente con Visual Studio.
  • VisualSVN Server è un pacchetto che contiene tutto il necessario per installare, configurare e gestire il server Subversion per il tuo team sulla piattaforma Windows. Include Subversion, Apache e una console di gestione.

Ecco un grande libro su questo argomento: Version Control with Subversion di C Pilato

Controllo versione con Subversion http://ecx.images-amazon.com/images/I/51iwjNGkQdL._BO2,204,203,200_PIsitb-sticker-arrow-click ,TopRight,35,-76_AA240_SH20_OU01_.jpg


Un’altra buona alternativa a VSS e SVN è SourceGear Fortress che ha il sistema di rilevamento dei problemi oltre al controllo del codice sorgente – tutto in uno. O SourceGear Vault : solo controllo del codice sorgente. Inoltre c’è la soluzione SourceAnyWhere . Se hai bisogno di una soluzione Microsoft piuttosto che andare con TFS anziché VSS.

Microsoft ha ammesso di non usare mai VSS su nessuno dei loro progetti interni (al momento non riesce a trovare il riferimento: /). L’ho usato per due anni ed è stato stupido. Il database è stato danneggiato almeno una volta alla settimana.

Inoltre, una delle mie cose preferite da citare agli utenti VSS è la prima citazione sulla pagina di Eric Wadworth , secondo quanto riferito da qualcuno di Microsoft:

"Visual SourceSafe? It would be safer to print out all your code, run it through a shredder, and set it on fire." 

Sicuramente vada con SVN. VSS è come gli incubi di 1000 demoni.

Prendi in considerazione uno strumento più moderno come Git , Mercurial o Darcs . Ci sono molti vantaggi, lascerò il google come esercizio al lettore.

Usiamo SVN dove lavoro e con la documentazione giusta, il client e gli strumenti giusti è un gioco da ragazzi – finora è altamente affidabile lavorare con. Dopo aver trascorso gli ultimi 10 anni con VSS posso dire che non mi manca un po ‘.

Mi piace così tanto SVN che ho scritto una recensione di quelli che considero i client più preziosi (alcuni non lo sono) e altri strumenti. Questo è un nuovo articolo quindi è di grande attualità: http://codertools.wordpress.com/2009/03/24/svn-subversion-clients-and-other-tools/

Non esiterei a raccomandare SVN a chiunque – GIT è il prossimo sulla mia lista a guardare .. Spero che questo sia utile.

Evitare il mal di testa di un arresto anomalo del database di Source Safe con l’intera base di codice è enorme.

Non doversi preoccupare di chi ha estratto un file è un altro.

Trovo che unire i file con VSS sia molto complicato, ma è bello con SVN. Inoltre, e non ho alcuna prova di ciò, ma SVN sembra più veloce.

VSS è vecchio e obsoleto. Il database viene corrotto troppo spesso. C’è un motivo per cui MS ha creato anche TFS.

SVN è molto popolare (il che significa molto supporto per la comunità, che significa supporto gratuito), ci sono molti strumenti ad esso collegati (CruiseControl per l’integrazione continua ad esempio) ed è piuttosto semplice da usare.

Devi considerare che c’è una curva di apprendimento se stai già utilizzando VSS e questo è qualcosa che devi pesare nella tua ricerca. Se gli altri sviluppatori non hanno usato SVN (o CVS), allora potrebbe essere costoso, anche se tutto ciò di cui hai bisogno è una persona che conosce veramente il sistema e quindi istruisce il resto.

Siamo passati da VSS a SVN 4 anni fa e da allora non abbiamo più guardato indietro.

Proprio come una parte, abbiamo usato Sourcegear Vault per un certo numero di anni abbastanza felicemente. Avere repository e un database SQL Server centrale con un ottimo accesso agli internet ha reso il gioco un po ‘schifoso per la nostra organizzazione.

Penso che abbia un prezzo ragionevole e almeno valga la pena dare un’occhiata.

AnkhSVN 2.0 è davvero molto buono.

Se avessi l’integrazione di Visual Studio come requisito, avrei avvisato contro SVN anche un anno fa, ma questo è cambiato in maniera significativa. Non è ancora buono come, per esempio, VS Team System, ma è molto meglio della vecchia integrazione VSS basata su MSSCCI. Non c’è motivo per non utilizzare SVN con .NET.

Un altro voto “sicuramente SVN” qui. Facevo parte di un team di migrazione in un precedente lavoro. Non posso dirti quanto è stato bello sbarazzarsi di VSS.

  • Niente più repository corrotti
  • Molto meglio la fusione
  • Molto più veloce
  • Branching economico e facile
  • Niente più blocco esclusivo
  • Controlla la fonte in più posizioni molto facilmente

Potrei andare avanti, ma i ricordi delle catene VSS sono troppo dolorosi. Dì semplicemente di no.

SourceGear Vault è un eccellente sostituto di VSS. Ha iniziato a essere “funzionalità VSS ma utilizzando un vero database”, e da lì è cresciuto.

Quasi sicuramente SVN. SVN ha un diverso modo di lavorare (Copia-Modifica-Unisci invece di Blocca-Modifica-Sblocca). È un po ‘una curva di apprendimento, ma è il modo in cui le cose sono andate avanti da diversi anni, quindi la maggior parte degli sviluppatori dovrà impararlo a un certo momento o altro. Lock-Modify-Unlock è troppo doloroso, e ci sono seri problemi di collaborazione a cui realmente contribuisce, che sarei felice di spiegare se sei curioso.

In secondo luogo i commenti su quanto sia cattivo VSS. Ecco vari link che trattano l’argomento:

http://www.codinghorror.com/blog/archives/000660.html

http://www.developsense.com/testing/VSSDefects.html

http://wadhome.org/svn_vs_vss.html

Modifica: Vedi anche: Controllo del codice sorgente – Blocca / Unisci?

Parlando come qualcuno che ha attraversato il processo di transizione VSS -> SVN per una grande base di codice, direi che il più grande vantaggio è riuscire a dormire sonni tranquilli sapendo che il tuo sistema SCM non avrà improvvisamente un singhiozzo che corrompe il tuo database e devi tornare indietro al backup di ieri. Fai il backup del tuo database ogni giorno, giusto?

Con VSS, la corruzione è avvenuta almeno una volta al mese. Con SVN (stesso hardware e sistema operativo) – non una volta in oltre due anni.

Oh, e le capacità di ramificazione / fusione sono dolci!

Sicuramente, vai con SVN, per tutti i motivi sopra indicati. Potresti provarlo ankhsvn che è un plugin svn per visual studio. In questo modo puoi ottenere il meglio da entrambi i mondi: utilizzando SVN e tutto il lavoro viene comunque svolto all’interno di Visual Studio.

Solo un’aggiunta alla risposta di Koista Navin.

Ha detto: Ecco un grande libro su questo argomento: Version Control with Subversion di C Pilato

C’è una versione online gratuita:

http://svnbook.red-bean.com/

Team Foundation Server è la scelta ottimale per lo sviluppo nel mondo .NET. Tuttavia non è gratuito e per la versione attuale 2008 può essere piuttosto costoso. Se si dispone di un pacchetto di livello superiore per Visual Studio, si ottiene TFS workgroup edition gratuitamente che consente a 5 utenti di accedere senza costi aggiuntivi.

Ci sono alcune importanti avvertenze per l’edizione del gruppo di lavoro è necessario utilizzare uno dei 5 slot per l’account del servizio TFS a meno che non lo si imposti per l’esecuzione in un account utente che verrà incluso nell’elenco dei membri TFS. L’altro è che una volta raggiunto il limite di 5 utenti, il passaggio a 6 utenti è un costo piuttosto sbalorditivo in quanto gli attuali requisiti di licenza comprendono la necessità di acquistare il server (poche migliaia di dollari) e le licenze CAL per ogni membro del team. Questo è un costo abbastanza proibitivo per aggiungere un altro membro al team.

Tuttavia, Microsoft è venuto a realizzare questo e sta cambiando questo per il 2010. Non sarà più necessario acquistare il server stesso e sarà solo necessario acquistare CAL. Licenze server TFS 2010: è incluso negli abbonamenti MSDN