Cours d’apprentissage du Framework Ogre avec Python

Cours d’apprentissage du Framework Ogre avec Python

1.1. Section UI

1.1.1. Nom d'utilisateur

Au minimum, vous devez définir votre nom d'utilisateur et votre adresse électronique, qui vous identifient:

[ui]

nom d'utilisateur = Joe Bloggs <joe@bloggs.com>;

1.1.2. Ignorer la liste

Dans cette section, vous voudrez probablement définir une liste d’ignorations globale afin de ne pas avoir à

configurer les fichiers ignorés par référentiel. Par exemple:

[ui]

nom d'utilisateur = Joe Bloggs <joe@bloggs.com>;

ignorer = c: \ hgignore_global.txt

Donc, ici (sous Windows), je fais référence à un fichier de liste d’ignorance que j’ai créé à l’emplacement c: \ hgignore_global.txt. UNE

assez bon début pour une liste globale ignore pourrait ressembler à ceci:

syntaxe: glob

* ~

* .orig

* .rej

* .swp

. # *

* .obj

* .o

*.une

* .ncb

* .lk

*.EXE

* .dll

* .lib

*.manifeste

* .pdb

* .idb

* .rsp

* .pch

* .dep

*.alors

* .dylib

*.cadre

Vous pouvez évidemment ajouter d'autres éléments à cela si vous le souhaitez.

1.2. Les extensions

Nous vous recommandons d’activer quelques extensions Mercurial pour le développement d’OGRE; cela se fait tout simplement dans le fichier de configuration.

1.2.1. Extensions communes

Votre fichier de configuration doit inclure au moins les éléments suivants:

[extensions]

progrès =

rebase =

greffe =

L'extension Progress vous donne simplement plus d'informations sur l'avancement des opérations.

L'extension Rebase vous permet de réappliquer vos commits en plus des modifications apportées au référentiel maître, lorsque quelqu'un d'autre a transféré leurs modifications sur le maître avant vous. Cela évite de devoir explicitement fusionner vos modifications avec les leurs, en gardant un historique compliqué. il semblerait que vous ayez appliqué vos modifications en plus de leurs modifications. Voir Tirer des changesets. L'extension Transplant vous permet d'extraire des commits individuels d'une branche à une autre, le cas échéant. Généralement, les modifications sont fusionnées entre les branches, mais il arrive parfois que vous ayez besoin de greffer des greffes individuelles.

1.2.2. Paramètres de diff

Mercurial peut générer des correctifs sous 2 formes différentes: - le format de correctif par défaut est compatible avec les utilitaires de correctifs GNU et tout autre outil les comprenant, et est donc très portable; Cependant, il ne peut pas gérer les fichiers binaires et ne peut pas gérer les renommements. Pour résoudre ce problème, Mercurial prend également en charge le format de correctif Git, qui intègre davantage d'informations et peut également gérer les fichiers binaires. C'est le format de correctif recommandé pour OGRE car il est beaucoup plus fonctionnel, même si cela signifie que vous devez utiliser Mercurial pour appliquer les correctifs.

[diff]

git = True

1.3. Windows spécifique

1.3.1. Traitement du texte

Etant donné que Windows traite les fins de ligne différemment de Linux et OS X, vous aurez besoin d'entrées supplémentaires dans votre configuration:

# à l'intérieur [extensions]

hgext.win32text =

[encoder]

** = cleverencode:

[décoder]

** = cleverdecode:

[crochets]

# Refuser les commits qui introduiraient des fichiers texte de style Windows

pretxncommit.crlf = python: hgext.win32text.forbidcrlf

Ceci est très important - par défaut, Mercurial n'effectue aucune conversion de fin de ligne. En activant l'extension win32text, tous les fichiers texte sont convertis en fins de ligne Unix avant la validation et convertis en fins de ligne Windows lorsque votre copie de travail est mise à jour. Cela garde tout cohérent. Les entrées cleverencode et cleverdecode déterminent si un fichier est du texte en cherchant s'il contient des caractères NUL; s’il n’en existe pas, il est supposé être du texte; s’il existe un ou plusieurs NUL, il est considéré comme binaire. Le crochet défini en bas est inclus pour éviter la validation accidentelle de fichiers avec les autres sources de données Windows.

1.3.2. TortoiseHg Spécifique

Si vous utilisez TortoiseHg [http://tortoisehg.bitbucket.org/], vous voulez certainement définir l’option suivante:

[tortoisehg]

postpull = rebase

Ceci définit l'action par défaut après avoir extrait les changesets pour redéfinir vos propres changesets exceptionnels par dessus

de cela. Vous pouvez également le trouver dans les Options globales sous Synchroniser> Après l'opération d'extraction.

1.4. Spécifique Mac OS X

1.4.1. Utiliser FileMerge

L’outil FileMerge inclus d’Apple est un outil de fusion à 3 voies extrêmement puissant que vous souhaitez vraiment utiliser pour les différences visuelles et les fusions manuelles. Il peut être lancé à partir de la ligne de commande en utilisant opendiff, mais malheureusement, si vous l'appelez directement, cela ne bloque pas l'exécution ultérieure dans la console, ce qui pose des problèmes pour Mercurial. Donc, la première chose à faire est de créer un script wrapper appelé "opendiffw" dans / usr / bin (ou ailleurs sur votre chemin), avec ce contenu:

#! / bin / sh

opendiff "$ @" | chat

Assurez-vous de chmod + x ce fichier. Ensuite, apportez les modifications suivantes dans votre fichier ~ / .hgrc:

[extensions]

hgext.extdiff =

[extdiff]

cmd.opendiff = opendiff-w

[fusionner les outils]

filemerge.executable = opendiff-w

filemerge.args = $ local $ autre -ancestor $ base -merge $ output

La première entrée rend la commande opendiff disponible afin que vous puissiez appeler hg opendiff au lieu de hg diff et ouvrira FileMerge au lieu de vous montrer un diff unifié sur la ligne de commande. La section mergetools rend opendiff la valeur par défaut lors de la fusion.

2. Utilisation de Mercurial

J'espère que vous connaissez déjà les principes de base de l'utilisation de Mercurial; sinon, veuillez consulter les didacticiels officiels de Mercurial [http://mercurial.selenic.com/wiki/Tutorial]. Cependant, Mercurial étant très flexible, des règles de base doivent être établies pour que l’équipe reste organisée.

2.1. Points généraux

2.1.1. Référentiel maître

Le référentiel 'maître' se trouve sur BitBucket ici: http://bitbucket.org/sinbad/ogre/. Je recommande aux développeurs d’utiliser le lien SSH (avec des clés SSH si vous le souhaitez) plutôt que https, car il est plus fiable lors de transactions volumineuses, car le délai d’expiration est beaucoup plus long.

2.1.2. Branches Officielles

Le référentiel maître utilisera des branches uniquement pour les flux de développement officiels, ce qui signifie en pratique une branche par version stable majeure, plus la branche par défaut (considérée comme "instable").

Par exemple, il peut s’agir de la liste des branches du référentiel maître:

défaut

v1-7

v1-6

Remarque

Lorsque nous utilisions Subversion, nous utilisions aussi des branches pour d'autres tâches, telles que des travaux expérimentaux incohérents pour l'inclusion officielle d'un membre de l'équipe ou un projet étudiant sur Google Summer of Code. Nous n'utiliserons plus de branches pour ces tâches. Au lieu de cela, toutes les autres divergences dans le code seront traitées en créant des clones du référentiel et non par des branches. Si ces clones doivent être publics, alors un fork devrait être créé sur BitBucket, et toutes les personnes intéressées peuvent l'utiliser. Plus tard, si le travail dans ces fourches doit être réintégré dans le référentiel maître, les modifications peuvent être soumises sous forme de correctif ou (de préférence) les modifications associées à l'historique de validation complet, si cela a du sens.

Pointe

Si vous avez des modifications expérimentales de longue durée dans votre propre référentiel privé, effectuez-les dans un clone local pour les séparer des modifications que vous souhaitez transférer en amont vers le maître. Ceci est similaire aux branches locales de Git (qui ne sont pas forcées à moins que vous ne le demandiez), et il existe en fait une extension non officielle de Mercurial pour supporter cela, mais je ne le recommande pas. Un clone est simple à gérer et vous voudrez quand même le tester. Il est donc utile de disposer d’une copie de travail distincte.

2.2. S'engager

2.2.1. Principes généraux

Essai

Mercurial vous permet de s’engager localement, ce qui signifie que votre flux de travail est plus rapide. Cependant, en tant que développeur principal chargé de transmettre les modifications au maître, vous devez toujours vous assurer que toutes vos validations sont cohérentes en soi, c'est-à-dire que chaque étape de l'historique du référentiel est générée et exécutée. Il est possible de ré-mélanger les commits que vous avez effectués ultérieurement à l’aide des files d’attente Mercurial, mais uniquement si vous n’avez pas repoussé les commits auparavant. En général, il est préférable d’essayer de maintenir la cohérence de vos commits tout le temps. Alors commettez souvent, car une histoire riche est toujours préférable, mais vérifiez au moins que tout est compilé et exécuté avant de créer un nouveau commit.

Commits cohésifs

Vos commits devraient être aussi concentrés que possible sur un seul sujet. Essayez de ne pas valider les modifications à des fins multiples à la fois, il est beaucoup plus difficile de séparer ces modifications ultérieurement si nécessaire. Et surtout, ne commettez jamais de correction de bogues et de changement de fonctionnalité dans un seul commit, à moins que le changement de fonctionnalité ne soit le seul moyen de corriger le bogue (dans ce cas, il ne peut être corrigé que dans la branche unstable par défaut).

Changements inutiles

Bien qu'il puisse être tentant de "ranger" le code, de corriger l'indentation, de normaliser, etc., vous devriez généralement éviter de le faire pour son propre compte. Si vous changez quand même le code, résolvez certainement tous les problèmes de formatage et de normalisation dans la zone en question pendant que vous y êtes. Toutefois, des modifications purement esthétiques ne doivent jamais être engagées, car elles peuvent toutes entraîner une fusion de véritables modifications - entre branches et acceptation de correctifs - bien plus difficiles en raison de conflits provoqués simplement par des modifications de formatage triviales.

2.2.2. Correction de bogues

Les corrections de bogues doivent toujours être d'abord validées dans la branche stable actuelle (en supposant qu'elles l'affectent). Ainsi, par exemple, au moment de la rédaction de cet article, les corrections de bugs doivent être validées dans la branche v1-7. Ces corrections de bugs seront fusionnées vers l'avant dans la branche par défaut périodiquement. Les raisons de s’engager dans la branche stable d’abord et de fusionner, plutôt que de s’engager dans la branche par défaut et de sélectionner les commandes à transplanter dans la branche stable, sont nombreuses:

• Il encourage les tests primaires et les engagements rapides sur la branche stable, qui est l’une des solutions les plus urgentes.
• Les conflits de fusion se produisent toujours dans la branche instable, pas dans la branche stable. C'est encore mieux parce que la branche stable est le plus important pour rester le plus propre possible
• La fusion est automatique. Vous voulez toujours fusionner TOUTES les modifications de la branche stable dans la branche par défaut. Aucune erreur humaine n'est impliquée dans la sélection des modifications à fusionner. Si vous corrigez cherrypick pour mettre en communication la branche stable, vous devez vous assurer de ne rien manquer, de ne pas inclure accidentellement un changement d'interface, etc. Et si quelqu'un a validé un correctif combiné et un changement d'API dans un commit (voir ci-dessous) c'est un gâchis.

2.2.3. Validation de nouvelles fonctionnalités et modifications radicales

Toute nouvelle fonctionnalité ou modification qui modifie l'API ou le comportement dans l'API existante doit toujours être validée dans la branche par défaut (souvent appelée instable).

2.3. Pousser / tirer

Pousser et tirer est la façon dont vous obtenez les commits vers et depuis les référentiels distants, respectivement. Ceci est principalement couvert dans les tutoriels et la documentation Mercurial. Cette section s'intéresse à l'approche recommandée pour les problèmes communs.

2.3.1. Pousser les changesets

C’est très facile à faire, vous pouvez utiliser hg sortant et hg push (ou l’équivalent graphique) pour envoyer le

changesets (commits) que vous avez déjà apportés au maître.

Pointe

Par défaut, la cible de push and pull est l'endroit où vous avez cloné le référentiel. Si vous faites un clone local de votre référentiel, rappelez-vous que l'emplacement de transfert / extraction par défaut sera l'origine locale et non le maître. Modifiez le fichier .hg / hgrc pour indiquer l'emplacement par défaut (ou pour ajouter des alias).

Cependant, il est fréquent que vous essayiez de transmettre vos commits au maître, mais que vous obteniez une erreur disant:

abort: push crée de nouvelles têtes distantes!

(avez-vous oublié de fusionner? utilisez push -f pour forcer)

C’est un message qui prête à confusion, mais la raison la plus courante est que quelqu'un d'autre a mis ses validations avant vous, et vous n'êtes pas autorisé à appliquer vos modifications tant que vous n'avez pas résolu ce problème. Les nouvelles têtes distantes font référence au fait que vous créeriez effectivement deux flux de développement parallèles différents sur la branche en question, et vous ne pouvez pas (ou plutôt ne devriez pas) pousser cela, bien que vous puissiez le faire localement. Le conseil "(avez-vous oublié de fusionner? Utilisez push -f pour forcer)" n'est pas un bon conseil non plus. Vous ne voulez presque jamais utiliser push -f, et dans le cas le plus courant d’être obsolète avec les modifications en amont, la meilleure option est de fusionner - voir Section 2.3.2, «Tirer un changeet» pour plus de détails. Si vous avez réellement créé plusieurs têtes pour une branche localement - ce que vous avez peut-être fait délibérément en validant deux ensembles de modifications parallèles à partir de la même base, ou parce que vous avez extrait ou importé quelqu'un d'autres modifications qui étaient basées sur une révision antérieure, vos choix sont comment unifier ceux-ci avant de pousser. Voir Développement parallèle pour plus de détails.