Oui, mais certainement pas ceux de la bonne gestion des branches, et crois moi, quand tu veux réécrire une partie d'une appli (évidemment, ça n'arrive jamais comme problème, vu que tout le monde pense générique et bien foutu et pas du tout à la deadline et à la livraison), ca change les choses.
* En un an, pour les différents rewrite sur mon projet tournant sur SVN, voici les scenarii :
- Je ne bosse qu'en local, à la fin je tente un merge avec ce qui se trouve sur le serveur, au final j'en merge 75% et par erreur pouf, je commit le reste par dessus les commit d'origine : oui, evidemment, j'avais eut le tort de déplacer un repertoire ou deux, et comme je les ai déplacé avec un drag end drop et non exporté/supprimé/créé/reimporté, bah les .svn pointaient pas au bon endroit, ca se voyait pas, du coup j'ai fait du caca, et j'ai absolument pas mergé cette partie, sasn oublié que le commit final m'a demandé de faire 150 cleanup et 75 release lock ....
Après je fais un appel au test des 25 autres deeloppeurs pour verifier que toutes les dernière modifs sont ok, et savoir celle qui ne le sont pas
- Je me dis, j'ai progressé avec svn, maintenant j'ai qu'a utiliser le super système de branche. Je créé une branche je bouge des repertoires, mais la je me fais pas avoir, dans mon tortoise (ou eclipse, meme combat) je fais un export avant, je créé la destination, je reimporte les fichier au bon endroit et je supprime l'original.
Ya sans doute un client svn (aka, celui de base en ligne de commande) pour gérer les "mv" mais bon, mon but est de faire une manip que les autre pourront faire après sans se poser trop de questions (il auront pas envie d'ouvrir une super console windows pour aller jusque dans leur workspace, s'inquieter du path, etc.).
Là, je dois merger ma branche et curieusement ca veut pas merger avec le tronc. Pourtant je lui donne bien la dernière version de ma branche a merger avec la dernière version du tronc.
Marche pas.
J'abandonne : export de la branche, redownload complet du tronc dans un autre repertoire, je colle par dessus, et je regarde ce qu'il m'indique avoir besoin de committer. Bon evidemment, poyur les fichiers que j'ai deplacé, je tourne à la comparaison fichier par fichier sur les plus importants, je croise les doigts pour le reste. J'ai des charges à tenir, et comme la dernière fois, ça passera par un "svp testez tous, je viens de faire du bordel". Evidemment, il resta quelques problèmes par oubli de fichier, et certains fichiers sotn resté en double dans l'arborescence pendant 2 semaiens (oubli de suppression).
- Je me dis on va faire les chose bien, cette fois je vais lire la doc. pis déjà, pas de répertoire à déplacer cette fois, ouf. Je dis à mes chefs qu'on va faire une doc pour qu'on puisse industrialiser le processus. Je lis la doc de SVN, et je comprend grossomodo ce qu'il faut faire.
Je me fais un petit teste en local, et j'arrive a faire un merge en ne modifiant qu'un fichier, puis un repertoire. Bien! Apprendre à le faire ne m'aura que couté une demi journée.
Vu que c'est pas méga intuitif (et oui, n'oublions pas de merger la version n-1 de ma branche avec la dernière version du tronc, ou le contraire, je sais plus, ou alors c'est le n-1 de la version qui sépare le tronc de la branhce ? je sais plus), je fais meme un petit screencast car ca va plus vite que de faire une doc à laquelle personne n'aurait rien compris pour faire le merge (cf. doc svn).
Bon finalement je fais ma branche, puis je dois passer sur une autre partie du projet, un collègue doit prendre ma suite, evidemment, le jour du merge, il ne regarde pas mon screencast car pense que le merge de branche est assez naturel et au final, apres une journée de galère arrive à merger (en plus j'étais en vacances ce jour là)... à coup d'export/import.
J'ai appris plus tard qu'il était dejà spécialiste des override and commit et de raler sur les gens modifiant le même fichier que lui.
- Dernièrement : je sais que faire une branche est un gros bordel, ma video s'est noyée dans le wiki dans le wiki de doc developpeur, mon planning est super serré (faire des rewrite est considéré uniquement comme un cout, rarement comme quelquechose permettant à l'application de mieux tourner ...). je commence une experience d'un dev avec un risque que ça ne fonctionne pas.
Au pire j'abandonne cette idee au bout de 2 jours. Ce qui se produit. Je continue donc le reste et override and update les fichiers que j'avais modifié.
Pas de merge pour cette partie.
Il y a 2 semaines, le point bloquant empêchant mon "developpement experimental" de fonctionner est résolu, et coup de bol j'ai 2 jours de dispo pr le reintegrer.
Evidemment, comme j'ai pas fait de branche, tout en local (je deteste ça), bah hop je n'ai plus rien. La modif ne sera donc jamais faire (ou pas avant de long long mois).
Ca c'est passé comme ça parce que je savai que j'aurai pas le courage de remerger la branche et de faire les deplacements de repertoires et fichiers via svn (je ne sais toujours pas comemnt faire d'ailleurs).
Avec un gestionnaire de version avec un système "naturel" j'aurai pas eut ce problème.
* En dehors des rewrite, notre svn derrière apache sur notre serveur de dev semble avoir des problèmes incompréhensibles qui plantent les clients svn.
Dans ce cas, on se loggue sur le serveur, on passe root, on redemarre l'apache, qui n'était pas tanké pour autant, mais qui laisse des connexions ouverte sur le svn, plus rien ne bouge: la plupart du temps ça arrive sur les gros commit ou les checkout, ou quand plusieurs developpeurs font pas mal de petits commits/updaet en même temps.
Evidemment il faut redemarrer les clients (dans eclipse ca veut dire fermer et rouvrir eclipse, c'est pas comme si c'etait immédiat).
La semaine dernière le svn+apache plantait toues les 15-20 minutes. J'arrivais même pas à finir mon commit avant que ça replante, evidemment ça me laissait des lock, et il me fallait faire des clean up et des release lock, j'ai même eut droit à des erreurs sur le cleanup me demandant de faire des exports/suppression/update/reimport/diff/commit des fichiers concernés.
Je n'ai perdu que mon après midi... pas grave.
Bref: si la plupart des problèmes viennent de notre utilisation de "noob" de svn, il nous créé bien des problèmes et nous fait perdre beaucoup de temps à cause de ses fonctions peu pratique et absolument pas naturelles (j'avais vu une conférence chez google d'un certain Linus T. disant exactement la même chose, il a 10000 fois raison là dessus... d'ailleurs ça l'a décidé à faire son propre système de gestion de version, un certain Git je crois !).
Pourquoi est on toujours sous SVN alors ? D'abord, car les décideurs ont du mal à comprendre le problème, ensuite et surtout parcequ'on manque d'intégration sous Windows d'autres système, comme des DVCS, dont ils ne voient pas l'intérêt (personne n'a besoin de commiter dans un avion là... par contre ils s'en foutent que le serveur de dev de svn marche à mi-temps...).
Bah personnellement, les DVCS, j'en voit l'intéret : faire sa branche dans son coin, ou travailler à 2 avec un pauvre partage Windows (je sais c'est pas le bon endroit pour parler de cet OS, néanmoins je suis cantinné dessus au boulot, à cause d'exchange... et qu'on me parle pas du plugin d'evolution avec lequel j'ai terrassé les serveur de courrier lors de mes derniers essais !), c'est très simple. Le serveur de dev marche pas ? Pas grave je commit sur un serveur de secour, ou sur un partage sauvegardé, je mergerait plus tard.
Le problème :
Bazaar: sous windows, existe en standalone, mais si on veut une integration eclipse, c'est python+bazaar+plugin bazaar+plugin-eclipse+config plugin qui n'est pas encore tout à fait au point, et il faut rajouter : svn-patché + plugin bazaar pour pouvor tenter de faire un checkout du svn dans un repo bazaar ... Le tout pour se rendre compte que vu que je peux pas me connecter en https + user/mot de passe, de toute façon j'y arriverai pas.
Git : install windows ok, integration eclipse: moyen (derivé du plugin de bazar de memoire), j'arrive meme pas à lef aire tourner, et je sais meme pas comment faire mon checkout à partir de SVN même si je sais Git capable de le faire.
Mercurial: pas tenté mais semble du même accabi que les 2 précédents.
J'ai pas testé les tortoiseXXX pour les DVCS cités, mais une intégration à Eclipse serait tout demême bien plus pratique (par exemple pour l'intégration avec Mylin)
Ces dvcs sont prometteurs, sympathiques et tout, mais il leur manque une bonne intégration sous windows (evidemment, je préfèrerais bosser sous Linux), et la possibilité de travailler facilement avec un serveur SVN (pour pouvoir montrer que la transition est interessante) sans avoir de limite (comme https/login & mdp) et avec une installation en demandant pas 1 mois de recherche et de bookmark pour y arriver.
J'attend vraiment une certaine maturation de ces produit pour leur sauter dessus dés qu'un de ceux-ci peut m'aider dans mon travail. En attendant, je râle presque quotidiennement sur notre SVN :/
[^] # Re: J'ai pas compris la différence
Posté par Temsa . En réponse au journal Pourquoi Git m'importe ?. Évalué à 5.
* En un an, pour les différents rewrite sur mon projet tournant sur SVN, voici les scenarii :
- Je ne bosse qu'en local, à la fin je tente un merge avec ce qui se trouve sur le serveur, au final j'en merge 75% et par erreur pouf, je commit le reste par dessus les commit d'origine : oui, evidemment, j'avais eut le tort de déplacer un repertoire ou deux, et comme je les ai déplacé avec un drag end drop et non exporté/supprimé/créé/reimporté, bah les .svn pointaient pas au bon endroit, ca se voyait pas, du coup j'ai fait du caca, et j'ai absolument pas mergé cette partie, sasn oublié que le commit final m'a demandé de faire 150 cleanup et 75 release lock ....
Après je fais un appel au test des 25 autres deeloppeurs pour verifier que toutes les dernière modifs sont ok, et savoir celle qui ne le sont pas
- Je me dis, j'ai progressé avec svn, maintenant j'ai qu'a utiliser le super système de branche. Je créé une branche je bouge des repertoires, mais la je me fais pas avoir, dans mon tortoise (ou eclipse, meme combat) je fais un export avant, je créé la destination, je reimporte les fichier au bon endroit et je supprime l'original.
Ya sans doute un client svn (aka, celui de base en ligne de commande) pour gérer les "mv" mais bon, mon but est de faire une manip que les autre pourront faire après sans se poser trop de questions (il auront pas envie d'ouvrir une super console windows pour aller jusque dans leur workspace, s'inquieter du path, etc.).
Là, je dois merger ma branche et curieusement ca veut pas merger avec le tronc. Pourtant je lui donne bien la dernière version de ma branche a merger avec la dernière version du tronc.
Marche pas.
J'abandonne : export de la branche, redownload complet du tronc dans un autre repertoire, je colle par dessus, et je regarde ce qu'il m'indique avoir besoin de committer. Bon evidemment, poyur les fichiers que j'ai deplacé, je tourne à la comparaison fichier par fichier sur les plus importants, je croise les doigts pour le reste. J'ai des charges à tenir, et comme la dernière fois, ça passera par un "svp testez tous, je viens de faire du bordel". Evidemment, il resta quelques problèmes par oubli de fichier, et certains fichiers sotn resté en double dans l'arborescence pendant 2 semaiens (oubli de suppression).
- Je me dis on va faire les chose bien, cette fois je vais lire la doc. pis déjà, pas de répertoire à déplacer cette fois, ouf. Je dis à mes chefs qu'on va faire une doc pour qu'on puisse industrialiser le processus. Je lis la doc de SVN, et je comprend grossomodo ce qu'il faut faire.
Je me fais un petit teste en local, et j'arrive a faire un merge en ne modifiant qu'un fichier, puis un repertoire. Bien! Apprendre à le faire ne m'aura que couté une demi journée.
Vu que c'est pas méga intuitif (et oui, n'oublions pas de merger la version n-1 de ma branche avec la dernière version du tronc, ou le contraire, je sais plus, ou alors c'est le n-1 de la version qui sépare le tronc de la branhce ? je sais plus), je fais meme un petit screencast car ca va plus vite que de faire une doc à laquelle personne n'aurait rien compris pour faire le merge (cf. doc svn).
Bon finalement je fais ma branche, puis je dois passer sur une autre partie du projet, un collègue doit prendre ma suite, evidemment, le jour du merge, il ne regarde pas mon screencast car pense que le merge de branche est assez naturel et au final, apres une journée de galère arrive à merger (en plus j'étais en vacances ce jour là)... à coup d'export/import.
J'ai appris plus tard qu'il était dejà spécialiste des override and commit et de raler sur les gens modifiant le même fichier que lui.
- Dernièrement : je sais que faire une branche est un gros bordel, ma video s'est noyée dans le wiki dans le wiki de doc developpeur, mon planning est super serré (faire des rewrite est considéré uniquement comme un cout, rarement comme quelquechose permettant à l'application de mieux tourner ...). je commence une experience d'un dev avec un risque que ça ne fonctionne pas.
Au pire j'abandonne cette idee au bout de 2 jours. Ce qui se produit. Je continue donc le reste et override and update les fichiers que j'avais modifié.
Pas de merge pour cette partie.
Il y a 2 semaines, le point bloquant empêchant mon "developpement experimental" de fonctionner est résolu, et coup de bol j'ai 2 jours de dispo pr le reintegrer.
Evidemment, comme j'ai pas fait de branche, tout en local (je deteste ça), bah hop je n'ai plus rien. La modif ne sera donc jamais faire (ou pas avant de long long mois).
Ca c'est passé comme ça parce que je savai que j'aurai pas le courage de remerger la branche et de faire les deplacements de repertoires et fichiers via svn (je ne sais toujours pas comemnt faire d'ailleurs).
Avec un gestionnaire de version avec un système "naturel" j'aurai pas eut ce problème.
* En dehors des rewrite, notre svn derrière apache sur notre serveur de dev semble avoir des problèmes incompréhensibles qui plantent les clients svn.
Dans ce cas, on se loggue sur le serveur, on passe root, on redemarre l'apache, qui n'était pas tanké pour autant, mais qui laisse des connexions ouverte sur le svn, plus rien ne bouge: la plupart du temps ça arrive sur les gros commit ou les checkout, ou quand plusieurs developpeurs font pas mal de petits commits/updaet en même temps.
Evidemment il faut redemarrer les clients (dans eclipse ca veut dire fermer et rouvrir eclipse, c'est pas comme si c'etait immédiat).
La semaine dernière le svn+apache plantait toues les 15-20 minutes. J'arrivais même pas à finir mon commit avant que ça replante, evidemment ça me laissait des lock, et il me fallait faire des clean up et des release lock, j'ai même eut droit à des erreurs sur le cleanup me demandant de faire des exports/suppression/update/reimport/diff/commit des fichiers concernés.
Je n'ai perdu que mon après midi... pas grave.
Bref: si la plupart des problèmes viennent de notre utilisation de "noob" de svn, il nous créé bien des problèmes et nous fait perdre beaucoup de temps à cause de ses fonctions peu pratique et absolument pas naturelles (j'avais vu une conférence chez google d'un certain Linus T. disant exactement la même chose, il a 10000 fois raison là dessus... d'ailleurs ça l'a décidé à faire son propre système de gestion de version, un certain Git je crois !).
Pourquoi est on toujours sous SVN alors ? D'abord, car les décideurs ont du mal à comprendre le problème, ensuite et surtout parcequ'on manque d'intégration sous Windows d'autres système, comme des DVCS, dont ils ne voient pas l'intérêt (personne n'a besoin de commiter dans un avion là... par contre ils s'en foutent que le serveur de dev de svn marche à mi-temps...).
Bah personnellement, les DVCS, j'en voit l'intéret : faire sa branche dans son coin, ou travailler à 2 avec un pauvre partage Windows (je sais c'est pas le bon endroit pour parler de cet OS, néanmoins je suis cantinné dessus au boulot, à cause d'exchange... et qu'on me parle pas du plugin d'evolution avec lequel j'ai terrassé les serveur de courrier lors de mes derniers essais !), c'est très simple. Le serveur de dev marche pas ? Pas grave je commit sur un serveur de secour, ou sur un partage sauvegardé, je mergerait plus tard.
Le problème :
Bazaar: sous windows, existe en standalone, mais si on veut une integration eclipse, c'est python+bazaar+plugin bazaar+plugin-eclipse+config plugin qui n'est pas encore tout à fait au point, et il faut rajouter : svn-patché + plugin bazaar pour pouvor tenter de faire un checkout du svn dans un repo bazaar ... Le tout pour se rendre compte que vu que je peux pas me connecter en https + user/mot de passe, de toute façon j'y arriverai pas.
Git : install windows ok, integration eclipse: moyen (derivé du plugin de bazar de memoire), j'arrive meme pas à lef aire tourner, et je sais meme pas comment faire mon checkout à partir de SVN même si je sais Git capable de le faire.
Mercurial: pas tenté mais semble du même accabi que les 2 précédents.
J'ai pas testé les tortoiseXXX pour les DVCS cités, mais une intégration à Eclipse serait tout demême bien plus pratique (par exemple pour l'intégration avec Mylin)
Ces dvcs sont prometteurs, sympathiques et tout, mais il leur manque une bonne intégration sous windows (evidemment, je préfèrerais bosser sous Linux), et la possibilité de travailler facilement avec un serveur SVN (pour pouvoir montrer que la transition est interessante) sans avoir de limite (comme https/login & mdp) et avec une installation en demandant pas 1 mois de recherche et de bookmark pour y arriver.
J'attend vraiment une certaine maturation de ces produit pour leur sauter dessus dés qu'un de ceux-ci peut m'aider dans mon travail. En attendant, je râle presque quotidiennement sur notre SVN :/