Dopo aver passato tutta la mattinata a cercare di controllare qualcosa - ora mi rendo conto di aver perso un paio di giorni di lavoro.
È già successo - ed è apparentemente un evento comune con SourceSafe. SourceSafe può essere utilizzato correttamente, senza problemi e, in caso affermativo, come?
La mia vista è semplice, migrare a qualcos'altro al più presto. Non ci vorrà molto (WAG 1-2 settimane) e non importa quanto tempo impieghi la migrazione, è facile costare giustificarlo alla direzione. Un po 'di tempo per migrare equivale a un solido controllo del codice sorgente e pochissime possibilità di perdita del codice sorgente. Fai una rapida ricerca su google per "storie horror sicure all'origine" o simili se il tuo capo è scettico.
Tutto ciò che è sbagliato in SCM è incorporato in VSS. Anche StarTeam è migliore di Source Safe. Source Safe è Internet Explorer 1 del mondo di controllo delle versioni: completamente sostituito da qualsiasi altra implementazione.
Come l'ho usato?
Il mio tipico flusso di lavoro per ottenere risultati era
In confronto a Subversion, quanto sopra è risibile (a parte controllare di non aver rotto la build).
Limitazioni alle pratiche di programmazione del mio team
Queste sono le regole che il team ha dovuto lavorare per farlo funzionare per noi. Il tuo chilometraggio può variare.
Che cosa si può fare?
Polarion ha un buon set di strumenti per la migrazione da Sorgenti sicure in Subversion (SVN) ) che è attualmente lo standard di fatto nella maggior parte delle aziende per il controllo della versione open source. Subversion non richiede che un server sia disponibile per consentire i check-in (a differenza di GIT o Mercurial progettati per i team offline distribuiti).
L'abbiamo messo fuori servizio circa un anno fa.
È successo più volte che quello che avevo controllato la sera prima non era il mattino dopo. Non l'ho trovato divertente perché sembrava sospettosamente come se non avessi finito il mio lavoro. Dato che ero nuovo nella società, allora potrebbe essere stato pericoloso per me.
Siamo passati al TFS e da allora ha funzionato senza problemi.
La mia vista?
Ce n'è di migliori che sono più facili da usare, più sicuri da usare e completamente gratuiti. Perché preoccuparsi di usarlo del tutto?
Questa è un'area di sviluppo in cui abbiamo un'ampia scelta; la maggior parte, o tutti, meglio di VSS.
L'uso di SourceSafe in un'operazione commerciale è come riscaldare l'edificio bruciando banconote da un dollaro.
Nel 2000, la mia società con otto sviluppatori ha probabilmente perso il 5-10% della sua produttività a causa della corruzione da due volte al giorno in media dei database VSS. Era solo così basso perché eravamo andati a backup orari.
Da quando ho spostato da VSS a Perforce, svn e git, non ho mai avuto un database SCM danneggiato.
Potrei essere votato all'inferno su questo, ma ...
VSS ti mette efficacemente di fronte alla droga, nella misura in cui non puoi conciliare alcun tipo di realtà necessaria per rendersi conto che il tuo repository non è stato colpa tua.
Per favore, non usarlo mai.
l'ha usato per anni: era la soluzione predefinita, perché era già lì. Mi ha morso un bel po 'di volte, ma l'inerzia è difficile da superare
quindi ho dovuto utilizzarlo da remoto tramite VPN e anche i check-in minori erano come riempire un mattone attraverso un foro stenopeico . È stato più rapido trovare manualmente i file modificati, comprimerli, inviarli tramite e-mail, eseguire il remote-in nella macchina del vault sorgente, decomprimerli e archiviare il codice dalla macchina del vault sorgente.
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.
L'ho usato per molto tempo (quasi 10 anni) senza mai aver avuto problemi personali (anche all'interno delle squadre in cui lavoravo, sebbene il nostro codice tendesse ad essere abbastanza ben diviso 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 il messaggio sembra evitare qualsiasi cosa complessa (ramificazione, unione, conflitti) e probabilmente stai bene. Qualcosa di più e ti stai dirigendo verso un territorio rischioso.
Anche MS lo sta deprecando a favore di TFS.
Per un solo o un piccolo negozio che lavora in Visual Studio 6 o qualcosa di più vecchio è passabile e meglio di niente. Penso ci sia un sacco di esagerazione su quanto sia stato male, ma poi ci vuole solo un istanza di perdere un lavoro prezioso per procurarti un prodotto (per una buona ragione). VSS ha avuto il suo posto, e lo merito per aver almeno incoraggiato molti sviluppatori che non stavano usando nessuno strumento SCM per prendere l'abitudine, ma come molte tecnologie ora è praticamente obsoleto.
Dopo 3 anni di utilizzo, lamentandomi con il mio manager a causa di tutte le alternative più avanzate / razionali là fuori, non ho mai avuto un problema con VSS, ma non ho mai avuto nemmeno un'opzione.
Le mie opinioni sono che fa schifo e botte.
La parte più noiosa a riguardo non è il terribile controllo delle versioni e l'abilità di ramificazione, ma la casella di riepilogo sul menu file non ti consente di premere il tasto freccia a destra per espandere.
Davvero doloroso.
La mia vista su VSS? Ho rifiutato alcune offerte di lavoro (molto ben pagate) perché richiedevano "competenza VSS". E sono sicuro che ci sono un paio di altre persone qui che hanno fatto lo stesso.
Non solo soffri del problema della potenziale corruzione dell'origine (che dovrebbe essere argomento sufficiente per la sostituzione da parte del management), ma devi anche vivere con un backup scomodo e l'incapacità di lavorare efficacemente come un team su diversi flussi di lavoro.
Trova un altro SCM (qualsiasi altro) e osserva come possono essere semplici diramazioni e fusioni. Pensa a quelle volte in cui hai dovuto copiare i file dalla tua soluzione VSS e tenerli da qualche altra parte mentre tornavi per correggere un bug sul codice "produzione".
Per i calci, basta installare GIT - puntarlo sui file VSS e vedere come è facile per GASP due programmatori lavorare su parti diverse dello stesso file ALLO STESSO TEMPO, e quindi avere il software unisce in modo intelligente le tue modifiche ... Gli strumenti SCM dovrebbero essere più di un semplice backup di origine.
Le mie opinioni su VSS? Usato per lungo tempo regolarmente (ancora usato occasionalmente per componenti più vecchi) ma è troppo XX secolo per il nostro team:
Sono di tutto questo: scegli una delle migliori alternative open source waaaay (anche CVS vecchio) o, se la tua azienda ha una sorta di abbonamento MSDN, TFS .
Il nuovo materiale della Team Foundation del 2010 avrebbe dovuto aiutare molto e cercare di allontanarsi dalle parti negative di VSS. Ma al suo interno si basa ancora su VSS , motivo per cui ci siamo trasferiti a SVN.
modifica - Capisco che TFS è tutto nuovo, ma quando lo collaudo, molti sviluppatori che ho chiesto hanno sentimenti molto simili. La ragione per cui ho detto "al centro" è perché ricordo che i file TFS creati nella mia soluzione sembravano esattamente come quelli creati da VFS. Questo è dal punto di vista dello sviluppatore, forse nemmeno conoscendo la tecnologia dietro VSS o TFS o qualsiasi altro SCM. Ci scusiamo per qualsiasi confusione.
Nel giorno in cui sono stato sellato con SCCS sotto XENIX. VSS, in Visual Studio 6, per tutti i suoi fallimenti e problemi ha avuto diversi vantaggi. Lo uso ancora per piccoli progetti e non uso più SCCS in nessuna versione.
Leggi altre domande sui tag version-control