2009-07-10 9 views
1

Remarque: Actuellement, vous utilisez Perforce en tant qu'outil CM.Comment déboguer les anciennes versions du logiciel?

Je réalise actuellement plusieurs versions de débogage de logiciels [uniquement des fichiers de débogage (.pdb) et des binaires (.dll et .exe)]. À chaque version, je vérifie tous les fichiers utilisés pour générer les binaires dans notre outil CM (baseline). Ensuite, je vérifie les fichiers et continue d'apporter des modifications. Actuellement, s'il y avait un problème avec l'une des versions de telle sorte que nous devions le déboguer, je devrais revenir à la version utilisée.

Ma question est, comment devrais-je procéder facilement au débogage des anciennes versions? Si je crée une branche à partir de la ligne de base que je viens de faire, alors je pourrais facilement construire la version précédente pour le débogage, mais qu'en est-il plus loin que cela? Je ne veux pas faire de branchement chaque fois que je fais une base de référence (à peu près sûr que je ne veux pas faire ça). Je sais qu'avec VHDL vous pouvez créer des builds avec des points de test et utiliser les outils Xilinx pour déboguer n'importe quelle version de VHDL. Existe-t-il une manière similaire de faire cela en VS (peut-être en utilisant les fichiers .pdb et certains outils externes)?

Comment allez-vous baser les révisions afin que vous puissiez facilement déboguer l'ancienne version?

+0

C'est pourquoi il aide à utiliser un outil de versionning où ramification est une opération simple et pas cher. J'utilise SVN - les branches et les copies sont essentiellement des copies paresseuses, donc si aucun changement n'est fait, aucun nouvel espace n'est repris dans le repro. désolé, je sais que ce n'est pas une réponse ... – eeeeaaii

+0

Est-ce que votre contrôle de source vous donne l'option de créer une étiquette au lieu d'une branche? Les étiquettes ne coûtent pas cher, vous pouvez donc en créer une pour chaque version, puis vous branchez à partir de l'étiquette si vous avez besoin de corriger les bogues. –

Répondre

2

Eric Sinc a un Source Control HOWTO fantastique qui couvre ce sujet (et beaucoup plus).

Je vous le recommande vivement, car ce type connaît ses affaires.

Vous seriez intéressé par Chapter 6: History et Chapter 7: Branches.

Ce truc m'a vraiment aidé quand je me suis renseigné sur le contrôle des sources et les stratégies de publication de logiciels.

0

avertissement - été un certain temps pour moi et Perforce:

Pour Perforce, je serais probablement aller de l'avant et « Tag » chaque version (en Perforce, les fichiers de marquage crée une étiquette)

Ensuite, vous pouvez checkout une balise pour le déboguer. Si vous devez faire des changements et pousser un "hotfix" contre cette ancienne version, vous pouvez créer une branche à partir de cette étiquette plutôt que de la tête.

Tagging est assez simple, "tag p4 -l // release2.0 dépôt/BCH/..."

Branching d'une étiquette est pas trop dur, vous devez créer une nouvelle branche puis intégrer à partir de l'étiquette source: «p4 integrate -b [branchname] -s //depot/bch/[email protected]»

Notez que vous pouvez également marquer les versions (historiques) précédentes du code, ou créer des branches de commits précédents aussi.

1

Avec p4 vous n'avez pas besoin de créer une branche pour remonter dans le temps. Tout ce que vous avez à faire est de synchroniser avec l'étiquette appropriée ou de changer le numéro. Par exemple, si vous deviez recréer la version 1.1 de ProduitX, et le dernier changement de p4 était le numéro de changement 2000, vous pouvez effectuer les opérations suivantes:

p4 sync //depot/ProductX/[email protected] 

ou si une balise a été utilisé, comme « Release1.1 "vous pouvez le faire:

p4 sync //depot/ProductX/[email protected] 

ou si vous ne pouviez pas comprendre ceux, vous pouvez même essayer de synchroniser à une certaine date.Tels que:

p4 sync //depot/ProductX/[email protected]/02/01:12:15:00 

Pour plus d'informations p4 concernant les révisions de fichiers, essayez ceci:

p4 help revisions 
Questions connexes