Visual Source Safe (l'ultima versione) è davvero così brutto? Perché? Qual è la migliore alternativa? Perché? [chiuso]

3

Nel corso degli anni ho costantemente ascoltato storie dell'orrore, ho sentito dire "Real Programmers Dont Use VSS", e così via. MA, poi sul posto di lavoro ho lavorato in due società, una, un pubblico molto noto che si affaccia su un sito web ad alto traffico, e un'altra soluzione di hosting "Web-Based" di servizi finanziari di fascia alta rivolta a società molto grandi e molto conosciute, che è dove attualmente risiedo e tutto funziona perfettamente (KNOCK KNOCK !!).

Interagisco costantemente con ESTREMAMENTE Vecchia tecnologia con alcune di queste istituzioni finanziarie .. VECCHIO COME NON VUOI CREDERE .. che mi porta alla conclusione che se funziona "LASCIARE", e che forse c'è qualche valore nella vecchia tecnologia? almeno un valore sufficiente per annullare una riscrittura !? giusto ??

C'è qualcosa di fondamentalmente imperfetto con la tecnologia sottostante utilizzata da VSS? Ho la sensazione che se avessi detto "qualcuno ha detto VSS Sucks", avrebbero supplicato di dissentire, molto probabilmente mi daresti questo aspetto come se non lo sapessi -ish, e non potrei mai riconquistare il loro rispetto e la mia credibilità (beh, quello " Sarò difficile da soffiare .. lol), MA, darmi una discussione che posso portare a qualcuno che ha codificato per 30 anni, che costruisce piattaforme che sfruttano la tecnologia attuale (.NET 3.5 / SQL 2008 R2), scrivere il proprio ORM con scaffolding ed è in grado di fornire una piattaforma di qualità che supporta migliaia di utenti simultanei su una soluzione host multi-tenant, e non è d'accordo con alcun beneficio derivante dall'avere il controllo del sorgente integrato, e tuttavia utilizza l'infame fonte di sicurezza visiva.

Ho una vasta esperienza con TFS fino al 2010, e onestamente penso che sia fantastico quando un team (oltre gli sviluppatori) può abbracciarlo. Ho lavorato fianco a fianco con qualcuno il cui duro SVN'r e da un punto di vista purista, vedo la bellezza in esso (ho bisogno di un po 'di più, fuori dalla mia SS, ma sicuramente è sufficiente). Quindi, perché tali smarties non stanno scappando da Visual Source Safe? sicuramente se fosse così brutto, sarebbe stato realizzato ora, e non sarei seduto qui con questo semplice vecchio sistema di Check In, Check Out, Resistente alle versioni, Label Intensive. Ma eccomi qui ...

Mi piacerebbe lasciare un argomento che sarebbe la fine di tutto, ma se è una questione di opinione e di esperienza personale, sembra esserci troppo margine per mantenere VSS.

AGGIORNAMENTO: Credo che il caso migliore sia quello di fare in modo che i sostenitori del VSS controllino le esperienze degli altri e ne attingano fino a quando non (per favore) non sperimentiamo noi stessi il fattore di rottura. Fino ad allora, non mi impegnerò in una discussione per migrare da VSS ..

AGGIORNAMENTO 11-2012: Così sono stato in grado di convincere tutti sul mio posto di lavoro che dal momento che MS sta abbattendo il Visual Source Safe potrebbe essere il momento di migrare su TFS. Sono stato in grado di convincerli e di recente ho aggiornato il nostro team a Visual Studio 2012 e TFS 2012. La migrazione è stata abbastanza indolore, è stato necessario eseguire analyze.exe che ha riscontrato un sacco di errori (non sono sicuro che abbiano mai influenzato il progetto) e quindi eseguire manualmente VSSConverter.exe. Ancora una volta, indolore, tranne che ci sono volute 16 ore per migrare per 5 anni di tutto .. e ora siamo su TFS .. molto più integrati .. molto più cool .. quindi tutto sommato, VSS è servito per anni senza scopo -su. Non c'erano storie horror e Visual Source Save come il controllo del codice sorgente funzionava bene. così a tutti gli inesperti (me incluso). non c'è niente di sbagliato nell'usare VSS. Non vorrei iniziare un nuovo progetto con esso, e sicuramente prenderei in considerazione la migrazione a TFS. (Non è davvero super difficile e un nuovo convertitore di tipo "wizard" è in uscita da un giorno all'altro, quindi la migrazione dovrebbe essere indolore). Ma dalla mia esperienza, ha funzionato bene e ha fatto il lavoro.

    
posta hanzolo 02.03.2012 - 17:55
fonte

4 risposte

8

Il problema fondamentale con tecnologie come Access e SourceSafe è che sono soluzioni per file condivisi. Questo li rende vulnerabili a crash catastrofici (sì, mi è successo prima).

Detto questo, se lavori in un ambiente di sviluppo molto piccolo , SourceSafe funziona perfettamente. I checkout sono esclusivi per impostazione predefinita (a meno che tu non attivi la modalità "checkout multiplo" , che non ho mai usato), il che significa che solo una persona può lavorare su un file in qualsiasi momento, ma se siete tutti in una stanza, non è un problema.

Tutti dovrebbero essere tenuti ad effettuare il check-in quando escono per la giornata. La persona che non effettua il check-in e poi si prende un giorno libero, compra le ciambelle quando torna.

    
risposta data 02.03.2012 - 18:07
fonte
7

Il problema non è quanto sia "vecchio". VSS ha risentito dello stesso problema riscontrato da molte tecnologie Microsoft: qualcosa originariamente progettato per un singolo utente aveva alcune decisioni di progettazione che hanno causato problemi a più utenti, come la mancanza di commit atomici e la dipendenza dall'accesso ai file condivisi.

Sembra che Microsoft abbia risolto molti di questi problemi nel 2005, ma è un po 'il caso di "troppo poco troppo tardi". A quel tempo la maggior parte delle persone si era spostata su altri sistemi che avevano altre caratteristiche moderne che amavano e nessuno dei problemi.

    
risposta data 02.03.2012 - 18:10
fonte
2

Il Libro SVN sottolinea una cosa molto critica che non mi ero ancora reso conto del valore ma ora lo approvo profondamente. Non ho uno straccio esatto, ma qui c'è il jist:

La filosofia VSS è che il conflitto è cattivo . Quindi evitare i conflitti (a titolo di esclusione) potrebbe sembrare una soluzione, ma questo non è davvero positivo.

In caso di SVN (e anche vero per gli altri) - prima di tutto, può esserci un meccanismo per unire le cose senza conflitti - ma anche se i conflitti si verificano, è una buona cosa! I conflitti implicano che due sviluppatori stavano tentando di fare qualcosa di simile simultaneamente e il conflitto lanciato da SCM, in realtà li costringe a parlare.

Conflicts motivates communication where as exclusivity locks you out

    
risposta data 02.03.2012 - 18:14
fonte
0

Spesso è una questione di priorità e costi. La modifica di un sistema di controllo del codice sorgente per un grande team di sviluppatori può distrarre da progetti con priorità più elevata e, anche se il software è gratuito, il costo in termini di tempo di sviluppo. Ho passato 2 transizioni da VSS a TFS e da VSS a SVN e non è stato così semplice come sperato. Il tuo manager non vuole dire a un VP che il suo progetto molto importante è stato ritardato a causa di un pazzo progetto interno del team.

È una specie di mentalità "se non è rotta, non aggiustarla". Lo si vede anche in altre aree, come la lenta transizione da Windows XP nei reparti IT aziendali. Fondamentalmente, affinché il cambiamento abbia luogo, devi dare ragioni logiche per cui il costo e i limiti di mantenere la vecchia strada è maggiore del passaggio a qualcosa di nuovo.

    
risposta data 02.03.2012 - 18:46
fonte

Leggi altre domande sui tag