Dawn of Light

Je m'en doute mais faut bien rigoler un peu

Pour information :
Language batch = fichier .bat = Windows seulement
Language script shell = fichier .sh = Linux seulement (beaucoup plus évolué et puissant)

Ah oui. Bon, je vois le principe, pas la pratique (normal ^^).

Ok, merci Leo (et Hunab) pour cette clarification... il va falloir expérimenter pour mieux comprendre.

Bon dimanche

Pas de problème

je n'aurais pas dis mieux que Leo !

Sinon:
point rouge = modification dans le répertoire des sources sous VCS
point vert = pas de modifications
point d'exclamation = modification conflictuelle

Apres, il y a un système qui permet de ne pas commit ni tenir compte de certains fichiers: ces fichiers sont purement et simplement non traités par le VCS

Les bonnes pratiques, c'est d'isoler la zone de compilation de la zone d'execution.
DOL:
- est compilé
- est copié dans un rep "serveur"
- les scripts sont ajoutés au rep "serveur"
- DOLSERVER.exe est lancé

c'est clairement pas formalisé donc chaque serveur doit + ou - avoir le sien. Bien souvent on y trouve aussi le dump de la base de donnée.

Les bonnes pratiques, c'est d'isoler la zone de compilation de la zone d'execution.
DOL:
- est compilé
- est copié dans un rep "serveur"
- les scripts sont ajoutés au rep "serveur"
- DOLSERVER.exe est lancé

Je comprends ça

Ce qui permet de mettre les sources de DOL à jour sans conflits ni perte de modification, de conserver les scripts propre au projet indépendamment de DOL.

J'imagine que ça passe aussi par un .bat pour copier de la zone de compilation à la zone d'exécution en automatique mais après comparaison des versions pour là encore éviter d'écraser les modifications propres au serveur ?

Il faut surtout que ton fichier "Batch" fasse la différence entre les binaires "re"-générés que tu veux mettre à jour (donc en général tu écrases tout ce qui est .DLL ou .EXE avec les nouveaux) et les fichiers "personnels" de type Config / Game Server Scripts / Fichiers de données (ceux là en général ne sont pas écrasés car ils correspondent à une adaptation du programme et pas simplement sa compilation)

Donc une fois le code "recompilé" tu dois exécuter toi même un genre de "Install.bat" qui fera la recopie dans tes dossiers de production (le plus simple étant de faire un fichier ligne à ligne avec un "copy .\lib\Machin.DLL c:\production\lib\Machin.DLL" tu ne devrais avoir qu'une dizaine de lignes...), de cette façon c'est toi qui contrôle finement ce qui est écrasé ou non

Les modifs propres au serveur sont en général non incluses dans la compilation: serverconfig.xml, base de donnée, etc..

C'est clair

Merci à vous deux !

Coucou !

Je me permets de relancer le sujet pour une petite question qui me concerne.

Actuellement, nous disposons d'un serveur dédié sur lequel se trouve une version de notre serveur, synchronisé sur le repository de DOL, afin de pouvoir le tenir à jour régulièrement.
Pour les facilités de développement, je dispose d'une copie sur mon poste personnel, que j'ai aussi synchro avec le repository de DOL.

Cependant, pour les mises à jour, je trouve intéressant de disposer d'un repository privé qui, permet de faire une synchro entre mon poste, et le dédié.

Seulement, du coup, j'utilise le repository privé sur mon dédié et sur mon poste perso. Je n'ai plus de lien avec DOL.

Y a-t-il une façon propre de travailler avec deux repository différents ? En switchant de l'un à l'autre quand c'est nécessaire ? (genre en travaillant en général sur mon repository privé, et en passant sur DOL quand des mises à jour sont effectuées ?) J'utilise Tortoise SVN, mais je pense ne pas connaître ses fonctions avancées.

Merci d'avance pour votre expérience

Bon, pour info j'ai trouvé une solution qui a l'air de marcher, même si j'ai peur de pas connaitre les rouages de subversion...

Je garde deux dossiers en local, un repo DOL, et un repo Assembla.
Je travaille sur assembla, et quand il s'agit de faire une mise à jour DOL, je copie tous les fichiers de assembla vers DOL (sauf le dossier .svn), j'update DOL, puis je fais le travail inverse (DOL vers assembla).

Voila, ça c'est s'il y a pas de conflit ... Sinon ça se corse.

Si vous avez d'autres pratiques, n'hésitez pas à me les enseigner

Non je pense que c'est la seule solution.
Mais je pense qu'il doit exister des clients svn multi-repository, surement professionnels.