Discussion :

[-N4w4k-]

Bonjour,

Voilà j'ai très peu de connaissance dans le versionning de projet et je ne suis pas certain de l'utiliser pour les bonnes raisons.. Je vous explique:

Il y a quelques temps j'ai été embauché pour faire la maintenance d'un site web (je n'avais jamais bossé dans le web avant), et on m'a indiqué qu'il y avait un repository svn et qu'il fallait y faire des sauvegardes du code régulièrement. Je n'avais jamais eu à faire du versionning mais ok, l'utilisation de base n'est pas très compliquée.
A l'aide d'un partage de dossier (emplacement réseau, lecture/écriture), j'ai accès au serveur de développement et je peux directement y ajouter et modifier des fichiers. Je faisais des commit chaque semaine et à chaque nouveau développement prêt à être livré sur le serveur de prod.
J'étais seul à coder alors c'était au top!
Seulement ça c'est compliqué puisque un autre développeur m'a rejoint et je ne suis plus très sûr que ce système soit le mieux à présent.

Est ce que ajouter/modifier/supprimer des fichiers sans aucune trace de qui a fait quoi et quand, entre chaque commit sur le repo svn, reste une bonne pratique?
Ou alors il faut que chacun crée une copie de travail sur notre pc, puis que l'on fasse des commit/update pour chaque modification de fichier?

Je ne sais pas vers quoi pencher.. ou bien il y a d'autres options que je ne connaisse pas?

Si vous pouviez m'éclairer à ce sujet..

[_KB_]

Salut,

Pourquoi utiliser un dossier partagé sur le réseau quand on a un outil de gestion de configuration ?
Normalement la bonne pratique est d'avoir un repository sur un serveur (outil de gestion de configuration centralisé, à la différence de Git).
Chaque développeur utilise un client SVN pour se synchroniser avec le serveur et travaille le reste du temps en local sur ce que l'on appelle le working copy.
Le plus délicat est la résolution de conflits lorsque les modifications de deux développeurs se chevauchent. Mais ce n'est jamais trop compliqué à résoudre.

Je te conseille de lire la doc officielle afin de mieux comprendre le concept (surtout les concepts fondamentaux du chapitre 1).

Juste par curiosité, comment tu t'y prenais avec ton répertoire partagé ?

[-N4w4k-]

Normalement la bonne pratique est d'avoir un repository sur un serveur (outil de gestion de configuration centralisé, à la différence de Git).
Chaque développeur utilise un client SVN pour se synchroniser avec le serveur et travaille le reste du temps en local sur ce que l'on appelle le working copy.

Le truc c'est que sur le serveur, c'est une working copy aussi! Alors à chaque modification de la working copy sur mon poste local, je fais un commit du code de mon poste, je me connecte en RDP sur le serveur de DEV, et j'y fais une update de la working copy. Autant dire que c'est assez lourd quand il faut faire cette manip 100 fois dans la journée, car perso je sais pas coder du code propre et testable du premier coup, il y a toujours des fautes de frappes, des oublis d'import de librairie, sans compter l'évolution normal du code...

La semaine dernière je me suis fais un petit tool qui enchaine le commit sur mon poste local, update sur le serveur, et redémarre tomcat quand c'est nécessaire, donc le temps d'utilisation de SVN n'est plus trop un problème mais le fait que 90% du log svn qui ressemble à "Commit: correction faute de frappe" continue de me géner..

Il y a quelques années j'avais installer Git sur mon pc domestique afin de pouvoir partager du code sur Github. Je faisais des commit quand je le souhaitais et chaque révision avait un sens..

C'est ce problème de "révisions inutiles" qui me pose soucis...

Juste par curiosité, comment tu t'y prenais avec ton répertoire partagé ?

Je me connectais en RDP au serveur et faisais des commit de la working copy du serveur quand je sentais que c'était nécessaire.. C'est d'ailleurs ce que fait mon collègue encore aujourd’hui, car il trouve débile de faire des commit toutes les 30 sec pour pouvoir tester ses pages.. et je commence petit à petit à revenir à cette méthode..

[_KB_]

Mais pourquoi avoir un working copy sur le serveur et pas sur ton local? Il te suffit de faire un checkout sur ton poste de travail.
Ainsi tu fais des commit quand tu le souhaites sans passer par un répertoire partagé !

[-N4w4k-]

Oui c'est l'utilisation la plus courante je pense.
Le truc c'est que le SVN appartient au client pour qui on développe, et l'installation a été faite avant qu'on rejoigne le projet. On n'a donc pas eu le choix.

Pour rappel, le projet est un site web (java).

Le serveur SVN ne se situe pas sur le serveur de dev, mais sur un serveur qui centralise les repository de dev, d’intégration et de production (back office et front office pour chacun).
Ensuite, sur chaque serveur web, il y a une copie de travail.

D'instinct je dirai que ça permet de bien séparer l'application web et la sauvegarde de celle ci, sauf que je vois mal comment s’insère le développeur dans ce genre de configuration..

Depuis la semaine dernière je suis revenu à la méthode "je développe direct sur le serveur web, sans aucune trace des modifications jusqu’à ce que je décide de faire un commit depuis celui-ci, quand je le souhaite"...
Je ne sais pas si c'est une méthode standard mais bon, au moins je peux coder sans trop de contrainte..