Utiliser Subversion avec Visual Basic 6

Question

Mon équipe passe bientôt de Visual SourceSafe à Subversion, tout en développant/prenant en charge un projet existant dans Visual Basic 6.0. J'ai donc quelques questions :

• Quel est le meilleur outil pour l’intégration de l’EDI Subversion dans Visual Studio 6 ?(ou est-ce que ça n'en vaut pas la peine...)
• Existe-t-il des bonnes pratiques pour utiliser Subversion avec Visual Basic 6.0 ?(types de fichiers à ignorer, etc.)

Answer 1

Je conviens que Tortoise SVN dans l'Explorateur Windows serait le meilleur moyen d'utiliser SVN avec VB6.

Le plus grand changement que vous constaterez lors de la migration vers SVN est l'idée que "Check out" et "Check in" ne sont pas exactement les mêmes que "Update" et "Commit"...ainsi, toute intégration IDE avec VB6 est limitée car VB6 prend en charge MSSCCI, un mécanisme d'extraction/d'enregistrement.J'ai utilisé une fois TamTam SVN (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) avec Visual Studio 2003, mais arrêté car je trouvais cela limitant.Fusion/branchement/blâme, etc.sont des fonctionnalités très puissantes fournies par Tortoise SVN qui n'étaient pas dans TamTam.Le Tigre a aussi http://svnvb6.tigris.org/, mais je ne l'ai pas essayé.

Encore une fois, même si vous obtenez très probablement un IDE pour fonctionner avec VB6, je ne le recommanderais pas car la plus grande force de la migration vers SVN est de briser la philosophie Source Safe d'enregistrement/extraction.

Answer 2

Étant donné que Subversion utilise un cycle de mise à jour/édition/validation (plutôt que d'archivage/extraction), vous devrez être particulièrement prudent avec les fichiers binaires.La plupart des formulaires en VB6 se composent de deux fichiers :MonFormulaire.frm et MonFormulaire.frx.Les fichiers *.frx sont binaires et ne peuvent donc pas être fusionnés.

Compte tenu de cela, je configurerais Subversion pour exiger le « verrouillage » sur les fichiers .frx.Cela signifie qu'une seule personne à la fois peut extraire le fichier.Ce faisant, vous garantirez qu'un seul développeur peut modifier ces fichiers à la fois, et il sera toujours clair qui est cette personne actuellement.Si vous ne le faites pas, vous vous exposez à des maux de tête majeurs.

Answer 3

Types de fichiers à ignorer :

*.vbw
Fichier d'espace de travail généré automatiquement lorsque vous fermez un projet et contient les fichiers que vous avez ouverts, etc.

MSSCCPRJ.SCC
Le fichier d'état du contrôle de source généré par l'IDE VB6 (si vous optez pour la solution de contrôle de SVN dans l'Explorateur Windows, vous devez désactiver le plugin de contrôle de source dans VB6 et celui-ci ne sera pas généré).

*.log
Il s'agit de fichiers générés en cas de problème lors du chargement de l'interface graphique d'un formulaire.Le fichier se trouve au même endroit que le fichier de formulaire avec un nom égal au fichier de formulaire.
Exemple: MyForm.frm génère MyForm.log.

Vous ne devriez bien sûr le faire que si vous ne disposez pas des fichiers journaux dont vous avez besoin dans le contrôle de code source...

Answer 4

En fonction de ce que vous envisagez de faire sur ces projets existants, j'envisagerais de ne pas changer.

Je vous conseillerais vraiment de passer à SVN.Je connais quelques projets qui ont perdu le code source parce que la base de données VSS a été corrompue.

Je pense qu'il existe des outils qui effectuent la migration de SourceSafe vers SVN.(Oui, une recherche rapide sur Google l'a confirmé.) De cette façon, vous ne perdrez pas l'historique des révisions.

Answer 5

Je suppose qu'il ne faut pas se soucier de l'intégration et simplement utiliser Tortoise SVN dans l'Explorateur Windows.

En ce qui concerne les types de fichiers à ignorer, testez-les, extrayez-les, construisez-les et voyez si des fichiers ont été modifiés (pour Visual Studio moderne, j'ai tendance à ignorer les fichiers .suo)

Answer 6

Pour le côté serveur, VisualSVN Server est une solution super simple, nous l'exécutons dans un environnement virtuel VMware et il bourdonne.

Si vous êtes un gars en ligne de commande, j'aime beaucoup l'interface de ligne de commande pour svn, je trouve moins déroutant d'accéder à certaines actions que la tortue, comme l'état du dossier.Mais si vous êtes un fan d'explorateur, la tortue est plus que suffisante, provenant d'un monde sûr.

Les principales choses à ignorer sont :

• Artefacts reproductibles (dll, pdb, exe)
• Paramètres spécifiques à l'environnement (c.-à-d.le fichier de paramètres pour vs, le fichier csproj.user, les fichiers .suo)

Answer 7

En fonction de ce que vous envisagez de faire sur ces projets existants, j'envisagerais de ne pas changer.

Lorsque l'on fouille dans le code existant, il est vraiment utile d'avoir tout l'historique et les blâmes.SVN est bien meilleur que VSS, mais vous perdrez l'historique lorsque vous changerez.

Si vous envisagez de développer beaucoup de choses en VB6, cela vaut peut-être la peine de passer à SVN, mais si vous envisagez d'en faire autant à l'avenir, cela vaut-il également la peine de revoir le projet ?

J'ai un problème similaire, seuls les projets existants sont en Delphi.S'ils étaient en VB6, je pense que j'envisagerais de les « mettre à niveau » vers VB.Net, juste pour des raisons de maintenabilité.