Attualmente sto lavorando in un ambiente che ha ancora VSS 2005. Attualmente non ho il potere di passare a Subversion, TFS, ecc.Come vivere con Visual Source Safe 2005?
Quali sono i trucchi principali a cui prestare attenzione con VSS 2005-- come posso usarlo al meglio per provare a salvare le mie versioni e non far esplodere il mio codice sorgente? Ad esempio, è meglio integrarlo con Visual Studio 2008 o semplicemente utilizzare il client VSS?
Non fare nulla di complicato con VSS. Penso che molte persone che non hanno mai avuto problemi con VSS lo usassero come condivisione file (cioè i file vengono controllati una volta e non vengono mai modificati) - ironicamente usando VSS come backup di file ordinario aumenta effettivamente le probabilità di perdite catastrofiche!
VSS ti annega in una raffica di domande male formulate. Non c'è una sola risposta a ciascuna domanda, dovrai fermarti e pensare a ciascuna di esse. Quando ti disconnetti da VSS ti verrà chiesto costantemente se vuoi passare a utilizzare VSS su IIS, se lo fai, non sarà ovvio come annullarlo.
Non utilizzare il plug-in VSS per ottenere un progetto iniziale o controllare un progetto. Il plug-in VSS tende a collocare i file in posizioni impreviste, utilizza il client VSS, che è molto più probabile che fornisca una struttura di cartelle che rispecchia la struttura del progetto in VSS.
Non utilizzare le funzioni di compilazione per diramare, non unire. Crea un nuovo progetto VSS (ovvero una nuova serie di cartelle) e controlla il codice come se fosse una cosa nuova di zecca quando hai bisogno di diramarti. Usa qualcosa di simile al confronto se hai bisogno di simulare un'unione.
Non rinominare i file, aggiungere invece nuovo, copia incolla, quindi eliminare. Questo rompe la catena cronologica ma ha meno aggravamenti
Non consentire più checkout, ma informalmente non lasciare troppo lavoro troppo sulla stessa area di codice, non lasciare che altri sviluppatori lascino che la loro versione diventi obsoleta quindi stai cercando di unire la tua vecchia versione della cartella di lavoro e l'ultima versione e VSS tende ad annegare gli sviluppatori junior in domande che non capiscono.
Non eseguire check-in estremamente grandi. Non utilizzare su una connessione di rete lenta senza prodotti di terze parti.
Se si utilizza il plug-in VSS in Visual Studio, utilizzare periodicamente il client VSS per confrontare e sincronizzare la cartella di lavoro, ma farlo per file, non in un batch.
Non lasciare che il repository diventi troppo grande. Dividere repository per lavoro non correlato.
Non lasciatevi ingannare dalla password di accesso. VSS non è più sicuro delle autorizzazioni NTFS sulla cartella.
Quando uno sviluppatore lascia la società, chiedi loro di annullare la cassa. È un ordine di grandezza più facile da annullare i checkout utilizzando la stessa macchina e le stesse credenziali utente e cartella di lavoro piuttosto che utilizzare l'account amministratore per annullare i checkout di qualcun altro.
Si applicano anche tutte le migliori pratiche per qualsiasi sistema di controllo sorgente, ad es. controlla le versioni successive dei binari come binaryfile.bin, non binaryfilev1.bin, binaryfilev2.bin, ma informa VSS che .bin o che cosa vuoi dire binario o proverà a fare unire il testo.
Non ho avuto altro che esperienze negative con il tentativo di integrare VSS con VS, quindi consiglierei di non farlo. Tuttavia, al momento avevamo a che fare con progetti ASP.Net 1.1, che non avevano la bella caratteristica di poter vivere ovunque in qualsiasi tipo di struttura di cartelle, e questo è principalmente il punto in cui stavamo incontrando dei problemi: provare a sincronizzare struttura del progetto con il repository VSS.
Oltre a ciò, posso solo suggerire di non effettuare il check-in del codice tramite una connessione VPN soggetta a cadute. In effetti ... suggerirei di non controllare mai il codice da remoto;) Se la connessione si interrompe nel mezzo di un commit, è possibile raddoppiare se il database è solo corrotto.
L'ultima volta che l'ho provato (molto tempo fa), l'integrazione di Visual Studio ha funzionato male con l'utilizzo dei rami di progetto VSS.
Io uso solo il client VSS.
Altre raccomandazioni:
Come vivere con Visual Source Safe 2005?
Alcol. Carichi di esso.
Eseguire un repository SVN stealth con un processo automatico che controlla gli ultimi file VSS ogni notte e li controlla in SVN.
Quando VSS muore (e lo sarà) dice al capo che abbiamo un secondo repository pronto per l'uso.
Buona idea! Assicurati che il tuo lavoro non faccia nulla che possa corrompere il database VSS perché se lo fai non lo vivrai mai :) –
Che tipo di problemi hai avuto? Ho usato l'integrazione VS con VSS per molti anni e non ho mai notato problemi importanti con l'integrazione? – mundeep
Penso che il problema fosse che quando si dirama un progetto (che significa avere un diverso insieme di revisioni degli stessi file), allora il file in cui il mapping da Visual-Studio a VSS non viene modificato, vale a dire semplicemente copiato nel nuovo ramo ... così Visual Studio continua a lavorare con il mainstream invece che con il ramo che volevi che usasse. È stato tanto tempo fa, anche se così YMMV. – ChrisW