Dopo aver trascorso tutta la mattinata a cercare di controllare qualcosa, ora mi rendo conto di aver perso un paio di giorni di lavoro.

È successo prima - ed è apparentemente un evento comune con SourceSafe. SourceSafe può essere utilizzato con successo, senza problemi e, in caso affermativo, come?

La mia visione è semplice, migrare a qualcos'altro al più presto. Non ci vorrà molto (1-2 settimane WAG) e non importa quanto tempo impiega la migrazione, è facile da giustificare per la gestione. Un po 'di tempo per migrare equivale a un solido controllo del codice sorgente e poche possibilità di perdita del codice sorgente. Fai una rapida ricerca su Google per "storie dell'orrore sicure alla fonte" o simili se il tuo capo è scettico.

Peggio. SCM. Mai.

Tutto ciò che è sbagliato in SCM è incarnato in VSS. Anche StarTeam è migliore di Source Safe. Source Safe è Internet Explorer 1 del mondo del controllo versione: completamente superato da qualsiasi altra implementazione.

Come l'ho usato?

Il mio tipico flusso di lavoro per fare le cose era

1. Dai un'occhiata al progetto
2. Blocca tutti i file (per evitare di fondersi con qualcuno che ha aperto le porte malvagie dell'Inferno)
3. Ha fatto il mio lavoro
4. Ogni giorno ho controllato le mie modifiche
5. Ho ricontrollato tutto e risolto tutti i problemi con l'integrazione
6. Riprovato

In confronto a Subversion, quanto sopra è ridicolo (a parte verificare che non hai rotto la build).

Restrizioni alle pratiche di programmazione del mio team

Queste sono le regole in base alle quali il team ha dovuto lavorare per farlo funzionare per noi. Il tuo chilometraggio può variare.

1. Una sola persona può modificare un file (Heaven ti aiuta se vanno in vacanza)
2. Non diramare è troppo difficile da gestire
3. Non tentare mai di tornare a una revisione precedente

Cosa si può fare?

Polarion ha una buona serie di strumenti per la migrazione da fonti come Source Safe a Subversion (SVN), che è l'attuale standard di fatto all'interno della maggior parte delle aziende per il controllo della versione open source. Subversion soffre della necessità di disporre di un server per consentire il check-in (diversamente da GIT o Mercurial che sono progettati per i team offline distribuiti).

Cambia il controllo del codice sorgente in SVN / Mercurial / Git e non guardare mai indietro!

L'abbiamo messo fuori servizio circa un anno fa.

È successo più volte che quello che avevo fatto il check-in la sera precedente non era lì la mattina successiva. Non l'ho trovato divertente perché sembrava sospettosamente come se non avessi finito il mio lavoro. Da quando ero nuovo nell'azienda, sarebbe potuto essere pericoloso per me.

Siamo passati al TFS e da allora ha funzionato senza intoppi.

La mia opinione?

Ce ne sono di migliori che sono più facili da usare, più sicuri da usare e completamente gratuiti. Perché preoccuparsi di usarlo?

Questa è un'area di sviluppo in cui abbiamo molta scelta; quasi tutti o meglio di VSS.

• Sovversione
• mutevole
• Idiota
• Di Più

Usare SourceSafe in un'operazione commerciale è come riscaldare l'edificio bruciando banconote da un dollaro.

Nel 2000, la mia azienda di otto sviluppatori probabilmente ha perso il 5-10% della sua produttività a causa della corruzione mediamente due volte al giorno dei database VSS. Era solo così basso perché eravamo andati a backup orari.

Da quando mi sono spostato da VSS a Perforce, svn e git, non ho mai avuto un database SCM danneggiato.

Potrei scendere votato all'inferno su questo, ma ...

VSS ti mette efficacemente al sicuro, nella misura in cui non riesci a conciliare qualsiasi tipo di realtà necessaria per rendersi conto che il tuo repository ora interrotto non era colpa tua.

Per favore, non usarlo mai.

lo usava da anni: era la soluzione predefinita, poiché era già lì. Mi ha morso parecchie volte, ma l'inerzia è difficile da superare

poi ho dovuto usarlo da remoto tramite VPN, e anche i check-in minori erano come infilare un mattone attraverso un foro stenopeico . È stato più veloce trovare manualmente i file modificati, comprimerli, inviarli via e-mail, accedere in remoto al computer del vault di origine, decomprimerli e controllare il codice dal computer del vault di origine.

Passato a Mercurial. Posso clonare l'intera base di codice sorgente attraverso la VPN in meno di un minuto. E non temo più la ramificazione.

Non ci torneremo mai più.

È un abominio. Ma ancora meglio di niente.

L'ho usato per molto tempo (quasi 10 anni) senza mai sperimentare personalmente alcun problema (anche all'interno dei team in cui lavoravo, anche se il nostro codice tendeva a essere diviso abbastanza bene per evitare conflitti e simili).

Ma ci sono troppe storie di perdita di dati per continuare a usarlo quando ci sono alternative open source decenti e affidabili là fuori.

Modifica: dai commenti sembra che il messaggio eviti qualsiasi cosa complessa (ramificazione, fusione, conflitti) e probabilmente stai bene. Qualcosa di più e ti stai dirigendo verso un territorio rischioso.

Perfino MS lo sta deprecando a favore di TFS.

Per un negozio da solo o veramente piccolo che lavora in Visual Studio 6 o qualcosa di più vecchio è passabile e meglio di niente. Penso che ci sia molta esagerazione su quanto sia stato male, ma ci vuole solo un esempio di perdita di lavoro prezioso per inacidire un prodotto (per una buona ragione). VSS aveva il suo posto, e lo merito per aver almeno incoraggiato molti sviluppatori che non utilizzavano affatto lo strumento SCM per prendere l'abitudine, ma come molte tecnologie ora è praticamente obsoleto.

Dopo 3 anni di utilizzo, lamentarmi con il mio manager a causa di tutte le alternative più avanzate / razionali là fuori, non ho mai avuto problemi con VSS, ma non ho mai avuto nemmeno un'opzione.

Il mio punto di vista è che fa schifo e colpi.

La parte più fastidiosa non è il terribile controllo delle versioni e la confusa capacità di ramificazione, ma la casella di riepilogo nel menu file non ti consente di premere il tasto freccia destra per espandere.

Davvero doloroso.

La mia visione su VSS? Ho rifiutato alcune offerte di lavoro (molto ben pagate) perché mi chiedevano "competenza VSS". E sono sicuro che ci sono un paio di altre persone che hanno fatto lo stesso.

Non solo soffri del problema della potenziale corruzione del codice sorgente (che dovrebbe essere argomento sufficiente per la gestione per sostituirlo), ma devi anche convivere con un backup scomodo e l'incapacità di lavorare efficacemente come una squadra su diversi flussi di lavoro.

Trova un altro SCM (qualsiasi altro) e guarda come possono essere facili ramificare e unire. Pensa a quelle volte in cui hai dovuto copiare i file dalla tua soluzione VSS e tenerli altrove mentre tornavi a correggere un bug sul codice di "produzione".

Per i calci, basta installare GIT: puntalo sui tuoi file VSS e vedi quanto è facile per GASP due programmatori lavorare su diverse parti dello stesso file ALLO STESSO TEMPO, e quindi fare in modo che il software unisca in modo intelligente le tue modifiche ... SCM gli strumenti dovrebbero essere più di un semplice backup di origine.

Le mie opinioni su VSS? Lo usavo da molto tempo regolarmente (ancora usato occasionalmente per componenti più vecchi) ma è troppo XX secolo per il nostro team:

• Molto inaffidabile
• Rami non utilizzabili
• Supporto delle versioni molto scarso, hai etichette ma (proprio come i rami) non realmente utilizzabili

Sono d'accordo con tutto quanto sopra: scegli una delle alternative waaaaay migliori open-source (anche vecchio CVS) o, se la tua azienda ha una sorta di abbonamento MSDN, TFS .

• il suo blocco predefinito rallentava gli sviluppatori e nessuno voleva rovinare la sua configurazione
• non si integra molto bene con altri servizi, ad esempio un'applicazione web di gestione dei progetti
• non funzionava bene con il nostro server CI pianificato

Le nuove cose del Team Foundation del 2010 avrebbero dovuto aiutare molto e cercare di scappare dalle parti cattive di VSS. Ma al suo interno si basa ancora su VSS , motivo per cui siamo passati a SVN.

modifica - Capisco che TFS è tutto nuovo, ma durante il test, più sviluppatori che ho chiesto hanno avuto sentimenti molto simili ad esso. Il motivo per cui ho detto "al centro" era perché ricordo di aver guardato i file creati da TFS nella mia soluzione che assomigliavano a quelli creati da VSS. Questo è da un punto di vista dello sviluppatore, forse nemmeno conoscendo la tecnologia alla base di VSS o TFS o di qualsiasi altro SCM. Ci scusiamo per qualsiasi confusione.

Ai tempi ero sellato con SCCS sotto XENIX. VSS, in Visual Studio 6, nonostante tutti gli errori e i problemi presentava notevoli vantaggi. Lo uso ancora per piccoli progetti e non utilizzo più SCCS in nessuna versione.

Non riesco a capire perché tutti vogliono badmouth VSS. VSS non è distribuito e lo è il controllo della versione distribuita

1. meglio
2. consente in pratica il controllo della versione non distribuita

Si prega di leggere questo .