Utilizzo di Subversion con Visual Basic 6

Question

Il mio team passerà presto da Visual SourceSafe a Subversion, sviluppando/supportando un progetto legacy in Visual Basic 6.0, quindi ho un paio di domande:

• Qual è lo strumento migliore per l'integrazione dell'IDE Subversion in Visual Studio 6?(o non ne vale la pena...)
• Esistono procedure consigliate per l'utilizzo di Subversion con Visual Basic 6.0?(tipi di file da ignorare, ecc.)

Answer 1

Sono d'accordo sul fatto che Tortoise SVN in Windows Explorer sarebbe il modo migliore per utilizzare SVN con VB6.

Il cambiamento più grande che troverai durante la migrazione a SVN è l'idea che "Check out" e "Check in" non sono esattamente la stessa cosa di "Aggiorna" e "Conferma"...pertanto, qualsiasi integrazione IDE con VB6 è limitata poiché VB6 supporta MSSCCI, un meccanismo di check-out/check-in.Una volta ho usato TamTam SVN (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) con Visual Studio 2003, ma mi sono fermato perché lo trovavo limitante.Fusione/ramificazione/colpa, ecc.sono funzionalità molto potenti fornite da Tortoise SVN che non erano in TamTam.Anche il Tigri ce l'ha http://svnvb6.tigris.org/, ma non l'ho provato.

Ancora una volta, anche se molto probabilmente riuscirai a far funzionare un IDE con VB6, non lo consiglierei poiché il punto di forza maggiore della migrazione a SVN è rompere la filosofia Source Safe di check-in/check-out.

Answer 2

Poiché Subversion utilizza un ciclo di aggiornamento/modifica/commit (piuttosto che checkin/checkout), dovrai prestare particolare attenzione ai file binari.La maggior parte dei moduli in VB6 sono costituiti da due file:MyForm.frm e MyForm.frx.I file *.frx sono binari e pertanto non possono essere uniti.

Detto questo, imposterei Subversion per richiedere il "blocco" sui file .frx.Ciò significa che solo una persona alla volta può estrarre il file.In questo modo, imporrai che solo uno sviluppatore alla volta possa modificare questi file ed è sempre chiaro chi sia quella persona attualmente.Se non lo fai, ti stai preparando ad avere grossi mal di testa.

Answer 3

Tipi di file da ignorare:

*.vbw
File dell'area di lavoro che viene generato automaticamente quando chiudi un progetto e contiene quali file hai aperto, ecc.

MSSCCPRJ.SCC
Il file di stato del controllo del codice sorgente generato dall'IDE VB6 (se utilizzi la soluzione di controllo SVN in Esplora risorse, dovresti disabilitare il plug-in del controllo del codice sorgente in VB6 e questo non verrà generato).

*.log
Si tratta di file generati se qualcosa va storto nel caricamento della GUI di un modulo.Il file si trova nella stessa posizione del file del modulo con nome uguale al file del modulo.
Esempio: MyForm.frm genera MyForm.log.

Ovviamente dovresti farlo solo se non disponi di file di registro necessari nel controllo del codice sorgente...

Answer 4

A seconda di quanto hai intenzione di fare su questi progetti legacy, prenderei in considerazione di non cambiare.

Ti consiglierei davvero di passare a SVN.Conosco alcuni progetti che hanno perso il codice sorgente perché il database VSS è stato danneggiato.

Penso che ci siano strumenti che eseguono la migrazione da SourceSafe a SVN.(Sì, una rapida ricerca su Google lo ha confermato.) In questo modo non perderesti la cronologia delle revisioni.

Answer 5

La mia ipotesi sarebbe quella di non preoccuparmi dell'integrazione e di utilizzare semplicemente Tortoise SVN in Windows Explorer.

Per quanto riguarda i tipi di file da ignorare, esegui un test, esegui il checkout, compila e verifica se qualche file è cambiato (per il moderno Visual Studio tendo a ignorare i file .suo)

Answer 6

Per il lato server, VisualSVN Server è una soluzione semplicissima, la stiamo eseguendo in un ambiente virtuale VMware e funziona perfettamente.

Se sei un tipo da riga di comando, mi piace molto l'interfaccia della riga di comando per svn, trovo meno confuso raggiungere determinate azioni rispetto a tortoise, come lo stato della cartella.Ma se sei un fan degli esploratori, la tartaruga è più che adeguata, proveniente da un mondo sicuro.

Le cose principali da ignorare sono:

• Artefatti riproducibili (dll, pdb, exe)
• Impostazioni specifiche dell'ambiente (ad es.il file delle impostazioni per vs, il file csproj.user, i file .suo)

Answer 7

A seconda di quanto hai intenzione di fare su questi progetti legacy, prenderei in considerazione di non cambiare.

Quando si scava nel codice legacy è davvero utile avere tutta la storia e la colpa.SVN è molto meglio di VSS, ma perderai la cronologia quando cambi.

Se intendi sviluppare molto in VB6, potrebbe valere la pena passare a SVN, ma se intendi fare così tanto in futuro, vale anche la pena rivedere il progetto?

Ho un problema simile, solo i progetti legacy sono in Delphi.Se fossero in VB6, penso che prenderei in considerazione l'idea di "aggiornarli" a VB.Net, solo per manutenibilità.