Dawn of Light

1- Telecharger TortoiseSVN*
http://sourceforge.net/projects/tortois ... urce=files

2- Utilisation du TortoiseSVN
Créer un répertoire du nom de DOL SVN
Effectuez un clique droit sur ce répertoire puis faite "create a repository here".
Jusque la ce n'est pas trop compliquer non ?
Ensuite faites un clique droit sur votre répertoire et clic sur "svn checkout".
Une nouvelle fenètre s'ouvre ou ils demandent d'ajouter une URL (une adresse électronique en gros), l'adresse est :
http://svn.code.sf.net/p/dolserver/code/DOLSharp/trunk
Une fois le lien mis clic sur "OK" pour commencer le telechargement de la source de DOL.

3- Mise a jour de la source
Pour effectuer une simple mise a jour il suffit tout simplement de clic droit sur le repertoire et de faire un "svn update".

4- Divers
L'avantage d'avoir une version en svn est indéniable.
On peut faire des modifications dans la source tout en étant à jour par rapport à dol.
Par contre il ce peut que la mise a jour écrase certaines de vos modifications donc faites attentions



*De base TortoiseSVN est en anglais, mais il est possible de rajouter des packs language pour rajouter la langue française ( http://sourceforge.net/projects/tortois ... e/download )

Les principales fonctions de TortoiseSVN :
(sous windows, accès par le clic droit)

svn show log : affiche les informations (commentaires, fichiers, date) associés au dernières révisions. Permet aussi d'afficher un intervalle de revision, ou toutes, grâce au bouton "Show range".

svn update : met à jour la source locale à la revision HEAD du serveur (la plus récente)

svn update to revision : met à jour la source locale à la revision entrée dans la boite de dialogue, (utile pour "revenir en arrière")

svn commit : propage la sélection sur le serveur.

svn revert : utilisée pour annuler des modifications faites sur la source locale. Récupère donc les fichiers de la revision HEAD. (Fonctionne par sélection)

svn add : Ajoute localement un ou plusieurs fichiers au repository (nécéssite un commit pour être effectif)

svn delete : supprime la sélection du serveur.

svn relocate : modifie l'adresse du serveur.

svn rename : renomme la sélection.


Erreur fréquente : J'ai ajouté un fichier/dossier que je ne voulais pas, sans avoir commit, je veux le supprimer :
Utiliser svn revert (et non svn delete) en sélectionnant le fichier/dossier.

J'ai renommé un fichier, et l'icone verte à disparu, il ne semble plus référencé :
Utiliser svn rename (et non la fonction renommer de windows)

Je rajoute qu'il existe un pack de localisation pour TortoiseSVN, si ca intéresse les refractaires à la langue de sa Majesté.

Mise à jours des liens car depuis 2007 et 2009 les liens ont légèrement changer.

Peux tu mettre à jour le lien du point 2 s'il te plait ?
http://svn.code.sf.net/p/dolserver/code/DOLSharp/trunk

Done !

Ca peux servir

Je relance ce sujet car un point m'échappe

Quelle est la bonne pratique pour modifier des fichiers (serverconfig.xml par exemple) sans qu'ils apparaissent avec un point d'exclamation rouge qui indique une modification par rapport au SVN (logique) et donc sans qu'il risque d'être écrasé lors d'un nouvel import depuis le SVN ?

J'espère être clair

Merci.

Tes fichiers locaux avec point d'exclamation rouge modifiés personnellement ne seront jamais écrasés, il peuvent à la limite être "Merge" s'il n'y a pas de conflit.

Le plus gênant c'est surtout pour les "commit" ou ce fichier sera constamment listé comme mise à jour potentielle...

Pour la résolution des conflits je suis pas très doué pour l'instant... Mais en tout cas SVN ne touche à rien tant que tu tente pas une résolution de conflit: après même chez moi je fais des catastrophe la dessus

Mais ta config XML devrait être dans un dossier "debug" ou "release" qui lui n'est pas sensé être versionnée (SVN_IGNORE)

Ah c'est pour ça que le dossier debug n'est pas taggué par le SVN... (oui c'est une découverte ^^).

Tu veux dire que lorsque l'on modifie un fichier, on le duplique dans ce répertoire non mis à jour et qu'il est pris en priorité par DOL sur l'original ou bien plutôt qu'il ne faut toucher qu'aux fichiers qui sont dedans mais sans en importer de nouveaux.

Je comprends bien la notion de répertoire orphelin vis-à-vis de SVN, c'est très logique, mais que peut-on faire (ou ne doit-on pas faire) dedans ?

Merci encore Leo, t'es partout et tu réponds à tout

Oui je suis un peu en recherche d'inspiration alors j'arrive pas à me pencher sur un truc concret

Pour SVN j'ai pas trop compris la problématique, les dossier debug/release ou encore obj ne sont pas versionnés car ce sont le résultat de la compilation, ça va dépendre de chaque environnement de travail de chaque développeur qui fait ses mise à jour dans son coin.

Typiquement les dossier debug/release sont les dossiers de travail, tu fais ce que tu veux dedans, ajouter des librairie, rajouter des gameserverscript, changer la configuration, modifier les XML...

Tout ce que tu risques dans ces dossiers c'est qu'une compilation écrase tes modifications, vérifie quels fichier sont écrasés/copiés entre deux "rebuild" (avec les date de fichier par exemple...), une mise à jour SVN n'écrasera pas les dossiers non versionnés et ne tentera pas de "merge" non plus par contre dès que tu vas compiler pense à garder une sauvegarde de modifications que tu fais en dur dans ton arborescence de travail (par exemple si tu modifies les zones.xml/regions.xml je suis plus sur si la compilation les écrase... dans la majorité des cas y a pas de dégats...)

Si tu dois préparer un "paquet" de tes propres fichiers à déposer dans le dossier de travail, prépare une arborescence, en dehors de ton SVN local, qui servira de "Patch", reproduit les sous dossier de travail de DOL avec tes fichiers personnels qui doivent compléter ou écraser les existants, comme ça si tu repars d'une compilation à zéro tu pourras toujours reproduire ton installation propre en quelques copier/coller !

J'essaye de comprendre comment le versionnage fonctionne, de manière très basique (en mode gros débutant) afin de ne pas faire d'erreurs. Voir des points rouges sur certains dossiers ça m'interpellent

Je vais lire la doc de SVN je pense que les réponses à mes incompréhensions sont dedans. Je comprends bien ce que tu m'expliques, mais je suis inquiet quand tu emploies un "dans la majorité des cas y a pas de dégats"

J'imagine que quelque chose a été pensé pour permettre une mise-à-jour dans un sens (de la source vers le serveur de prod) mais sans écraser les modifications côté prod ni aller polluer la source en retour. C'est sans doute très simple, mais comme j'utilise un outil (Tortoise) sans en comprendre les rouages, je me pose plein de questions existencielles

Pour prendre un exemple, quand je bosse sur un projet de CMS (type WordPress) il y a des mises à jour du logiciel (WordPress) et du thème qu'on utilise, mais il existe un ensemble de bonnes pratiques pour permettre au développeur de bosser sur une modification d'un thème de base de manière décorrelée, ainsi, peu importe si le logiciel et le thème sont mis à jour, le répertoire qui contient les modifications n'est jamais écrasé et n'interfère pas avec les sources. Et dans ce schéma, WordPress est conçu pour aller chercher en priorité les modifications dans le répertoire dit "enfant" et complète l'arborescence des fichiers avec ceux du thème orginal puis ceux de WordPress pour faire fonctionner le bazar. On modifie un fichier du source ? On le duplique dans le thème "enfant" et on le modifie là.

Je cherchais à comprendre si le SVN fonctionne ainsi, avec un répertoire pris en charge par le serveur (DOL) mais qui n'est pas mis à jour par le SVN afin de préserver les ajouts/modifications.

Mais comme je ne sais pas vraiment comment fonctionne SVN, tout ça n'est peut-être pas pertinent avec le sujet, donc je vais aller lire la doc et je te remercie d'avoir lu tout ça :p

Oui tu parles de déploiement la où SVN est un gestionnaire de version, il n'est pas utilisé pour déployer...

Les dossiers de travail debug/release c'est bon pour bidouiller mais ça ne doit surtout pas être un répertoire de production

Quand un répertoire est ignoré, c'est qu'il est ignoré ce n'est plus SVN qui se charge de ce qu'il y a dedans, pour ce qui est de DOL je sais juste que la compilation préserve correctement les "Scripts" du moins ceux qui ne sont pas dans le projet GSS (ceux là sont systématiquement recopiés)

si tu veux maintenir un répertoire de production tu dois créer un petit script (bat ou batch) pour recopier seulement les ressources qui t'intéressent ou à la limite utiliser des liens symbolique dans un répertoire à part, vers les ressources de DOL (il faudra surement linké les .exe et .dll de la racine un par un...) et après tu peu créer à coté des répertoires physiques qui ne seront jamais touchés par la compilation (et du coup tu peux aussi linké un à un les seuls scripts qui t'intéresse dans GSS)

Il ne faut pas oublier que GSS (GameServerScript) est un projet non compilé, les sources sont recopié dans le répertoire de travail sous le dossier "scripts" pour être compilé au démarrage du serveur, c'est ce qui permet une certaines flexibilité, mais après c'est à chacun de maintenir sont répertoire "script" pour ses propres besoins...

Par contre il faut un peu d'agilité pour pouvoir inclure ses modifications dans le "projet" cela permet de profiter de toute la puissance de son IDE (références aux objets DOL) et aussi d'avoir une compilation (qui ne sera pas utilisée !!) qui va au moins valider la syntaxe et certains autres aspects...

On ne peu pas manier du code managée comme on fait avec un script Perl ou Php, mais l'idée est là

Je suis un peu en train de me battre sur cette aspect, pour l'instant je crée un projet "à moi" à inclure dans la "solution" DOL seulement pour travailler, et ne pas "committer" les modifications de la solution... tout le reste semble "non touché" par cette méthode, mais il faut faire attention aux fichiers versionés ou non.

tu dois créer un petit script (bat ou batch)

Je tatillone mais c'est pas le même language ?

c'est malin :p

J'avais plutôt en tête "bat" ou "sh" dépendant du système cible