plop journal
Comme pas mal de boites / projets, à mon taff on utilise subversion.
C'est pas mal, ça marche, ça commit, ça update et depuis la version 1.5 ça gère les branches ... ça gère ? .... quoi ? ... des branches ... des quoi ? ... non tu déconnes là ... ou pas...
eurk !
non, définitivement non, les branches ça pue dans svn
Faire une branche ça roule.
Merger une branche après 1 mois de taff dessus ... ça devient galère (surtout si on en a déjà fait une partie, et oublié d'indiquer les numéros de révisions dans les commits...)
Merger une branche non complètement (venir piocher dedans) on peut s'en sortir
Merger deux branches en partie mutuellement (du trunk vers la branche, de la branche vers le trunk, jamais de manière totale) bof bof
Le tout est chiant !
Les merges sont galère, les svn:mergeinfo fleurissent, les conflits apparaissent, les indications de merge sont toujours zarb, ça me gonfle.
Depuis peu, on essai d'utiliser des branches assez souvent (des branches simplement expérimentales, des branches de maintenance, etc, le tout sur des projets nombreux dans le même repository avec des liens nombreux entre certains - svn:externals)
Mais forcément ça devient galère.
Donc je suis en train de voir pour intégrer un système décentralisé. Non parce que c'est à la mode mais parce que c'est vraiment pratique.
L'orientation de base étant le merge/les branches, on ne retrouve pas les problèmes récurrents de cvs/svn.
Il devient alors facilement possible de gérer des branches de dev, des branches de maintenance, des branches locales / privées pour des expérimentations, etc, le tout sans "trop" de casse tête.
La gestion des branches locales est également très pratique, surtout dans le cas où certaines personnes doivent / peuvent corriger des choses sans pour autant avoir un droit de commit dans la branche concernée.
Mais voilà, pour le moment tout tourne en svn.
On est donc en train de voir comment utiliser git-svn (qui est quand même vraiment sympa) ce qui permettrait d'y aller en douceur.
Mais étant donné que certaines personnes travaillant sur ces programmes sont peu expérimentées / peu ouvertes au principe d'une branche / simplement réfractaire à tout changement, elles empêchent en quelque sorte la migration totale vers un système décentralisé qui serait pourtant bien intéressant pour nous autres pauvres malheureux développeurs :'(
Comment c'est passés vos migrations cvs/svn vers des outils performants ? (git, mercurial, etc)
Connaissez vous des outils permettant soit d'exposer un dépot git en svn (surtout que nombre de clients existes) soit de synchroniser un dépot git (ou autre) avec svn ? (avec évidemment des commits des deux côtés...)
Certains ont-ils effectués ce genre de migration avec des utilisateurs peu habiles (peu connaisseurs de gestion de source) ?
(Si vous voulez troller sur git c'est nul c'est qu'un truc de linus pas cohérent et xxx c'est mieux ... vous pouvez y aller, ça donne souvent de bonnes infos - sauf le point pre-cité)
Journal migrations vers de vrai outils de dev...
25
mai
2009
# Les jounrnaux...
Posté par Zenitram (site web personnel) . Évalué à -9.
Bon, il y a bien une information : tu galères avec SVN (le reste étant une question).
Mais... euh... C'est tout comme info?
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . Évalué à 7.
ha non, y'a rien non plus, un commentaire vide, j'ai du rêver... ;)
L'info c'est que j'aimerais bien savoir comment se passent les migrations de softs svn -> un vrai truc, comment ça galère, comment gérer des miroirs, et que plein de monde ici utilise ça, et que j'avais envie de donner mon avis sur svn qui n'est pas génial pour certains point et que ....
Par contre tu aurais du lire un peu plus loin l'aide que tu cites, faut pas s'arrêter tout de suite hein ;)
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . Évalué à 7.
[^] # Re: Les jounrnaux...
Posté par Jérôme Nègre (site web personnel) . Évalué à 6.
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . Évalué à 3.
après l'affichage c'est un autre problème...
(en plus t'as un compte suffisamment vieux pour connaître ça, non ?)
[^] # Re: Les jounrnaux...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ça marche seulement quand tu poste sur IPOT, donc il est excusable, quand même.
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . Évalué à 3.
pourtant si je vais sur http://linuxfr.org/journal/new.html on me demande bien si je veux le publier en première ou deuxième page... (selon XP :))
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . Évalué à 2.
Cette vidéo est beaucoup beaucoup plus intéressante que je ne le pensais, même si on ne veut pas utiliser git. Je pense que quiconque réfléchissant un peu aux outils à utiliser pour faire du dev peuvent / devraient la regarder (bon après c'est du grand Torvalds hein, faut aimer ;) )
Sinon, pour le merge en svn, soit je ne suis pas allé assez loin, soit j'ai mal compris, soit pour moi c'était sur cvs :)
Il y a quand même eu des améliorations dans svn 1.5 mais c'est toujours pas au niveau attendu je trouve - enfin ça dépend de ce qu'on veut en faire...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les jounrnaux...
Posté par CrEv (site web personnel) . Évalué à 2.
Au début il tape sur cvs mais ensuite, au delà du fait que pour lui cvs et svn est quasi identique, il tape aussi sur la gestion (ou non gestion) du merge dans subversion
# oublis
Posté par CrEv (site web personnel) . Évalué à 3.
on trouve pas mal de chose pour faire des miroirs git -> svn mais unidirectionnel
Les miroirs svn sont toujours en lecture seule et aucun processus réel de synchronisation existe...
Par contre si quelqu'un connait un tel soft :)
# Je suis intéressé
Posté par dest . Évalué à 10.
Du reste, tu n'as pas posé simplement une question, tu as exposé ton problème afin d'initier un débat.
Et comme tu le précises nous avons eu récemment plein de journaux traitant l'informatique de loin et là, nous sommes en plein coeur.
C'est bien et ne te démotive pas à écrire des journaux.
[^] # Re: Je suis intéressé
Posté par rewind (Mastodon) . Évalué à 10.
Un VCS centralisé favorise le travail en communauté tandis qu'un VCS décentralisé favorise le travail individuel. Je m'explique.
Tout d'abord, il est bon de noter que je ne place absolument pas le débat sur le plan technique. Les reproches traditionnels qu'on fait à SVN (branch/merge difficile comme dans ce journal, pas de commits locaux, ...) ne sont que des foutaises, ce n'est qu'une histoire d'implémentation et ça se corrige et surtout, ça n'a rien voir avec le fait qu'il soit centralisé. D'ailleurs, il y aura bientôt des commit locaux dans SVN d'après ce que j'ai lu, il me semble. Donc tous les débats techniques qu'on voit fleurir à propos des divers VCS, ça ne rime à rien, c'est "juste" de l'implémentation et les features des uns arriveront chez les autres à un moment ou à un autre.
Ensuite, il faut voir ce qu'on appelle centralisé et décentralisé. Les trucs à la github, j'appelle pas vraiment ça décentralisé. Pour moi, un dépôt central où tout le monde commit et où on peut faire des branches, j'appelle ça centralisé, qu'on utilise SVN ou git. Qui utilise réellement les possibilités d'un VCS décentralisé (à savoir publier sa branche sur son site perso) ? Peu de projet. Et effectivement, déjà peu de projet s'y prête et ensuite, ça pose ce que je pense être des problèmes intrinsèques au modèle décentralisé.
L'utilisation d'un VCS centralisé, ça pousse les développeurs qui commitent à s'entendre entre eux pour ne pas faire de connerie, ça pousse aussi les contributeurs à prendre contact avec les développeurs pour connaître la meilleure marche à suivre. Donc ça favorise les contacts humain, la communauté. De l'autre côté, avec un VCS décentralisé, chacun peut faire sa branche, même si ce n'est pour modifier qu'une seule ligne et peut la publier fièrement, même si ça rentre en conflit avec le projet (donc impossible à merger). Un VCS décentralisé va favoriser les comportements individuels (bon ou mauvais d'ailleurs) plutôt qu'un comportement collectif autour du projet. Et ça peut mener à des dérives si jamais il n'y a pas un dictateur bienveillant qui organise le travail du collectif (genre Linus). Un VCS centralisé force ce comportement collectif techniquement.
Après, on peut aimer l'un ou l'autre. Moi, je préfère le travail collectif et donc, je n'utiliserai jamais git à moins d'y être forcé. J'aime bien SVN, il fait ce que je veux, point. Les features qui manquent, elles arriveront un jour, je ne me fait pas de souci.
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . Évalué à 6.
Moi ce qui m'intéresse aujourd'hui dans un truc comme git (s'il y a autre chose de mieux ça me gène pas hein ;)) c'est justement pas l'aspect décentralisé (même si c'est pratique) mais l'aspect branches.
Aujourd'hui, je dois me préparer à maintenir un trunk, 2 à 3 branches de maintenance, 1, 2 ou plus ça dépend branches de dev expérimental / choses ne rentrant pas dans le trunk par projet. (c'est du grossier)
avec un truc comme ça et un système comme svn c'est galère.
Alors oui c'est technique, mais ça pue.
Dans certains cas il est interdit à certaines personnes de commiter sur des branches de maintenance. Problème : certaines personnes vont tout de même créer des correctifs mais ne pourront jamais les versionner -> c'est le bordel, les commits ne ressemblent plus à rien, c'est chiant à faire, et s'ils sont pas intégrés rapidement c'est horrible.
Avec un système de branche ... c'est plus facile.
Le côté décentralisé ... ben heu ... c'est pas ce que je recherche, mais ça peu avoir des côtés intéressant, surtout lorsque l'un des développeurs veut se lancer dans une expérimentation sans polluer la branche principale, ni créer de branche distante sur le répo principal.
De puis, pour mon cas, ça reste une utilisation assez professionnelle et dans ce cas c'est pas l'outil qui pose des problèmes de communication, loin de là.
D'ailleurs un tel outil permet dans certains cas de mieux communiquer :
plutôt que de se retrouver un jour avec des commits apparaissant n'importe comment sans avertir les développeurs en charge, on va au contraire apprendre qu'untel a fait des modifs dans sa branche / nous a envoyé des patch et on va les intégrer.
Alors oui, gestion des droits, toussa, mais ça ne répond pas toujours aux règles fines qu'on souhaite.
(je sais pas si je me fais bien comprendre là...)
Un VCS décentralisé ne favorise pas plus le travail individuel, mais il garanti à chacun de pouvoir versionner son taff (très important, surtout quand on voit que certains ne comprenent toujours pas l'intéret...) à chacun de pouvoir améliorer le taff de l'autre, et aux responsables de pouvoir améliorer l'ensemble en prenant facilement les idées de tous.
Ca fait un peu fouilli dit comme ça mais c'est au contraire poser un cadre, des outils pour le réguler facilement.
> Moi, je préfère le travail collectif et donc, je n'utiliserai jamais git à moins d'y être forcé. J'aime bien SVN, il fait ce que je veux, point. Les features qui manquent, elles arriveront un jour, je ne me fait pas de souci.
C'est une erreur je pense, git est simplement un meilleur outil que svn. Il manque beaucoup trop de feature, et le fait d'ajouter des commits locaux ... voui mais tant que le merge ne sera pas utilisable franchement j'en veux pas.
Et les features ... ben c'est aujourd'hui que j'en ai besoin :(
[^] # Re: Je suis intéressé
Posté par Graveen . Évalué à 2.
N'ayant pas eu plus à faire que quelques merges sur des projets utilisés via SVN, je cherchais vraiment quels bénéfices je pouvais tirer d'un système plus "évolué", et ton post synthétise parfaitement mes conclusions.
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . Évalué à 2.
Ceci explique cela...
Fais-en un peu plus et tu comprendras ;)
Tiré d'un journal précédent, mais vécu de trop nombreuses fois :
(on peut remplacer tortoise par n'importe quel client svn hein...
(journal : https://linuxfr.org/~NoNo/26146.html )
[^] # Re: Je suis intéressé
Posté par Adrien . Évalué à 5.
ou bien à avoir une dictature de fer en ce qui concerne les commit…
Donc ça favorise les contacts humain
Justement dans une conf Linus pointait l'argument inverse :
Dans un truc centralisé il y a une « barrière » entre ceux qui peuvent commiter, et les autres. Ça peut créer des tensions si tu apportes pas mal de patch sans qu'on te donne les droits de commit par exemple.
Dans un système décentralisé tu code sur ton dépôts et si tes patch sont intéressants tu merge et basta. Il n'y a plus vraiment de différences entre ceux qui ont les droits de commit et les autres, tout le monde peut faire son dépôt librement et le synchroniser si c'est intéressant pour le projet.
je n'utiliserai jamais git à moins d'y être forcé
N'est ce pas un peu… dogmatique ?
Si tu arrives dans une communauté qui utilise massivement git tu feras ton autiste et utiliseras svn ? Ça me semble un peu contraire à tes idéaux de communauté…
[^] # Re: Je suis intéressé
Posté par rewind (Mastodon) . Évalué à 2.
Ça force celui qui veut vraiment commiter à s'intégrer à la communauté. Si celle-ci est vraiment réfractaire, là on ne peut plus rien pour eux.
> Dans un système décentralisé tu code sur ton dépôts et si tes patch sont intéressants tu merge et basta. Il n'y a plus vraiment de différences entre ceux qui ont les droits de commit et les autres, tout le monde peut faire son dépôt librement et le synchroniser si c'est intéressant pour le projet.
Combien de patch sont ramené à l'original ? Pour prendre un exemple connu : combien de "branches" de RoR existent-ils dans la nature ? Et combien vont voir leur features intégrées dans le projet original ? Faire ce qu'on veut dans son coin, git ou pas, ça exste depuis qu'il y a des sources. Un VCS décentralisé facilite le fait de faire un truc dans son coin, là où un VCS centralisé favorise le retour au projet initial, à mon avis.
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . Évalué à 4.
Heu non, avec une version décentralisé on a un outil permettant d'aider le développeur à le faire, en permettant dès l'origine (inclus dans les fonctionnalités de base) de fusionner son travail avec la branche principale.
Sans un tel outil, ça ne favorise en rien le retour au projet initial.
En continuant l'exemple de RoR :
un gars à une idée, un souhait à implémenter, qq chose à coder mais ne fais pas partie de l'équipe de dev, et ne veut de toute manière rajouter qu'une petite chose et ne pas en faire partie (ça arrive pour plein de raisons)
- avec une version centralisée : il va faire un checkout qq part, modifier son code, le garder en local et l'utiliser. Il a sa version modifiée. Si le trunk / tag / branche sur laquelle il s'est basé change ... ben c'est pas forcément facile, au mieux un svn up par exemple mais c'est pas forcément simple
- avec une version décentralisée : il fait son clone, fait sa branche propre, code son truc dedans. Jusque là il gagne déjà le fait que ce soit commitable dans sa branche. Il peut ensuite la publier s'il en a envie (et non envoyer des patch... ça a des bons et des mauvais côtés). Si la branche principale évolue ... ben c'est quand même un peu plus facile à gérer
Mais surtout, dans le deuxième cas s'il la rendue publique, et par exemple juste envoyé un mail en disant "j'ai rajouté tel truc" ça devient plus facile à intégrer ponctuellement que de lui autoriser à commiter dans le dépot principal ou récupérer des patch, y'a l'historique, toussa ...
Que tu n'ai pas besoin d'un système décentralisé je comprend. Qu'il y ait une telle aversion, j'ai plus de mal à comprendre...
[^] # Re: Je suis intéressé
Posté par rewind (Mastodon) . Évalué à 0.
Tu fais exactement ce que je dénonçais dès mon premier post, tu places le débat sur un terrain technique. Mais là, tu ne compares pas centralisé, décentralisé, tu compares SVN maintenant et git maintenant. Quand SVN aura les mêmes fonctionnalités que git à ce niveau là (commit locaux, etc), ton argument ne vaudra plus rien.
> Mais surtout, dans le deuxième cas s'il la rendue publique, et par exemple juste envoyé un mail en disant "j'ai rajouté tel truc" ça devient plus facile à intégrer ponctuellement que de lui autoriser à commiter dans le dépot principal ou récupérer des patch, y'a l'historique, toussa ...
Hormis le fait que quand SVN aura des commits locaux, il y aura l'historique aussi (débat technique inutile), on retrouve le clivage dont je parlais. Avec un VCS décentralisé, le gars va publier dans son coin, sans forcément en parler, et ça restera comme ça (comportement individuel par défaut). Avec un VCS centralisé, il va discuter avec la communauté pour qu'il puisse intégrer sa modification dans la branche principale (comportement collectif par défaut).
> Que tu n'ai pas besoin d'un système décentralisé je comprend. Qu'il y ait une telle aversion, j'ai plus de mal à comprendre...
J'ai une aversion contre l'individualisme. Mais après, j'empêche personne d'utiliser git.
[^] # Re: Je suis intéressé
Posté par CrEv (site web personnel) . Évalué à 3.
oui car le problème vient en bonne partie d'outils inefficaces
> Quand SVN aura les mêmes fonctionnalités
> quand SVN aura
> il y aura
oué ben quand il aura des fonctionnalités vraiment intéressante je reverrai peut-être mon jugement, en attendant il est à la ramasse. Et avoir des commits locaux ne servira à rien tant qu'on ne pourra pas faire de merge sereinement
Et comme le modèle de svn ne permet pas de le faire...
> Avec un VCS décentralisé, le gars va publier dans son coin, sans forcément en parler, et ça restera comme ça (comportement individuel par défaut). Avec un VCS centralisé, il va discuter avec la communauté pour qu'il puisse intégrer sa modification dans la branche principale (comportement collectif par défaut).
Oui mais au moins il l'aura publié
L'exemple que je prenais, et je l'ai justement précisé, partait du cas où la personne fait une modif initialement pour elle, sans vraiment se soucier du besoin d'autres.
Avec un système centralisé ou non il n'ira pas la proposer aux dev :
- pas de temps
- pas l'envie / le besoin
- communauté fermée (ça existe trop souvent aussi)
- besoin de "faire ses preuves" avant de pouvoir réellement proposer quelque chose
Mais dans un cas ce sera utilisable, dans l'autre il l'aura gardé en interne et personne n'en saura rien.
Alors oui, c'est technique mais dans ce cas l'outil peut permettre d'améliorer l'ensemble même pour quelqu'un que ça n'intéresse pas forcément et qui devrait faire des efforts avec un système centralisé incapable de gérer convenablement ce genre de cas
[^] # Re: Je suis intéressé
Posté par thedude . Évalué à 2.
Tu part du principe qu'un outil va influencer l'ouverture du projet.
Non, je doute.
Git ne fera pas d'ulrich drepper un agneau.
svn ne transformera pas linux en projet ferme a toute idee.
Le probleme du retour de contributions, c'est d'une part la mentalite du chef de projet, d'autre part celle du mec qui fait la modif.
Si le chef de projet est une tete de bite qui supporte pas les idees qu'il n'a pas eu, les contributions externes seront rares.
Inversement si le mec qui a fait la modif veut pas s'emboucanner a discuter avec l'equipe upstream, ben ca remontera pas.
Je sais pas, ca revient un peu a dire que tel projet est ouvert parce que les dev sont sous debian, ou ubuntu, ou red hat ou ce que tu veux.
Je vois pas franchement le rapport.
Que le projet utilise svn, git, cvs ou sourcesafe, ca va pas y changer grand chose.
[^] # Re: Je suis intéressé
Posté par jerome (site web personnel) . Évalué à 1.
Pour faire court, je crois que tu as réussi à te convaincre de l'intérêt des CVCS tout en confortant tes sentiments concernant l'action collective. C'est un comportement naïf, mais sécurisant pour toi. Je comprends.
Par contre, je ne suis pas sûr qu'il soit intéressant de le partager.
Pour ma part, mercurial&co sont tout simplement un véritable bonheur à utiliser et permettent une bien agréable liberté d'utilisation (dans le train sur son portable).
Si SVN envisage d'implémenter les commits locaux, alors hormis détails, nous assistons à une convergence vers le meilleur.
# git-svn n'est pas parfait
Posté par dohzya . Évalué à 3.
SVN, comme tu le dis si bien, n'aimes pas (ne connaît pas ?) les merges.
Donc si tu as un historique à la Git, soit avec une arborescence assez complexe, tu ne peux l'envoyer tel-quel dans SVN, car ce dernier sera perdu au premier merge Git (c'est pour ça que je me permet de dire que SVN ne connaît pas les merges : il permet de les effectuer, mais ils ne représentent rien). Tu dois donc aplatir ton historique avant de le passer à SVN.
Au final, tu te retrouves avec les même problèmes... mais tu te bats avec les outils de git, notamment la possibilité de faire toute ta m... crasse en local, et de n'envoyer le tout qu'une fois content du résultat. Mais tu perds quand même une bonne partie de l'intérêt de Git...
Personnellement, j'utilise git-svn au travail, car je connais bien et aime git, mais je pense qu'une version tout-git apporte un réel plus (ou plutôt un réel moins d'ennuis !)
[^] # Re: git-svn n'est pas parfait
Posté par ckyl . Évalué à 5.
On souhaitait passer à un modèle de dev basé sur les branches dans notre équipe, en ayant pour contrainte de devoir garder SVN comme dépôt officiel. De plus on ne souhaitait pas former tout les devs à un nouveau VCS.
On est donc parti sur git-svn depuis ~18 mois. Les résultats sont très satisfaisants: aucun problème pour merger ~40 branches (donc certaines de plus de 12 mois), souplesse de git pour les devs qui en ont besoin, les autres restent à SVN ça évite de former 30 personnes à git pour rien. Tout les essais de merge avec SVN (et svnmerge) avaient foiré avant. Bref ca fait ce qu'on veut, sans avoir couté cher.
Effectivement le problème du backend SVN est que tu perds les informations de merge, donc ca devient le bordel quand tu cherches dans l'historique. Faut être un peu organisé. Mais y'a pas de miracle...
Notre utilisation:
- Une branche par feature (donc merge trunk->branche pour se synchro, et branche -> trunk pour l'intégration)
- Une branche pour chaque branche de release (cherry pick trunk -> release et tags de la branche pour chaque version mineure)
- Branche git locale pour tout ce qui le nécessite (et possibilité de la publier sur le SVN si on constate que c'est plus compliqué que prévu)
Après tout dépend de ton cahier des charges. Un VCS moderne apporte plus de fonctionnalités mais ça coute cher en déploiement/formation/intégration. Tu ne peux pas faire ça en 1 mois et tu auras à former tout nouveau dev dans ton équipe. Surtout que y'a 1000 façons d'utiliser git.
git-svn ca permet de faire des merges sur un repo SVN sans rien changer pour les autres (tu les fais co leur branche et zou). Et pour les devs qui migrent ça apporte le confort de git.
Perso je ne m'amuserais pas avec des passerelles lecture/écriture sur un repo.
[^] # Re: git-svn n'est pas parfait
Posté par CrEv (site web personnel) . Évalué à 2.
On est en train d'essayer de faire quelque chose du genre justement (utilisation des branches entre autre)
Par contre c'est vrai que la perte des infos de merge me plait moyen, c'est pourquoi je cherche à utiliser git total avec juste une passerelle ... si ça existe.
Par contre, en passant, y-a-t-il eu des problèmes lors de l'utilisation de git-svn (sur 18 mois je pense que oui) ?
En fait j'ai pas de cahier des charges précis.
Le vrai besoin est de simplifier les branches (qu'on me parle pas de svk) pour que ce soit utilisé le plus possible (l'usage des branches répond à beaucoup de problèmes qu'on rencontre)
Donc je me suis penché sur git-svn (pour le moment je trouve ça très bien) mais si je peux passer direct en git ça ne serait que mieux, histoire de ne pas passer sur git-svn maintenant pour certains, et dans 2 mois de passer sur git. Surtout que le svn commence seulement à ressembler à quelque chose (personne s'en occupait, ça commitait n'importe comment, pas de log, pas de tags, pas de branche - ni même de dossier trunk - ...)
Mais mon problème est dans l'usage d'un tel outil par des personnes qui ... s'en foutent en quelque sorte, à qui ça n'apportera peut-être pas grand chose.
Maintenant, si c'est pas possible, si ça fait perdre trop d'informations, etc ... forcément ça devient problématique.
L'histoire de passer l'historique à plat entre autre...
Question subsidiaire : existe-t-il toujours des branches svn / autre de linux ? qqn sait comment elles sont faites / maintenues ?
[^] # Re: git-svn n'est pas parfait
Posté par ckyl . Évalué à 2.
Dans l'ensemble ca marche très bien. Faut juste pas chercher les problèmes à faire 150 sous branches croisées. Le seul vrai problème que j'ai eu c'est l'impossibilité de "svn dcommit" à cause de conflits au rebase après ~50 cherry pick pour une branche de maintenance. En refaisant l'opération par bloc de 10 c'est passé. Ça s'est produit une seule fois.
Autrement rien à signaler du coté de git-svn. Les quelques fois ou ça part en live, tu arrives toujours à sauver le coup avec un peu d'effort; contrairement à SVN ou j'ai déjà fini à faire des diff/patch à la mano.
Ça fait ce que je veux sans se vautrer et ça me coute 0 en admin et en formation.
> Mais mon problème est dans l'usage d'un tel outil par des personnes qui [...]
Git me semble une mauvaise option alors. La courbe d'apprentissage de git est assez ardue et je connais pas 2 personnes au monde qui l'utilise de la même façon. En plus avec un mélange de branche locale et remote mappées sur le repo SVN, ça ouvre encore plus de possibilités.
Soit tu leur trouves un VCS moderne avec une interface simple et tu penses que ça vaut le coup de former tout le monde. Grincheux et adaptes des GUI sous <MonOSFavoris, MonIDEFavoris> compris.
Soit tu les laisses sous SVN en écrivant bien les procédures pour qu'une branche soit mergée plus tard (surtout tu inclus une cible qui formate le code source dans ton processus de build). Et tu as une petite équipe sous git-svn qui gère le reste.
Tu peux aussi essayer de documenter *la* méthode de faire avec git dans ton projet. Maintenant on à du passer 50% de nos dev sous git, faut compter perdre 2/3 jours pour les mettre dans le bain et deux bonnes semaines à galérer. Et maintenant ils n'utilisent plus du tout git comme moi :-) D'une manière générale les gens sont passé à git-svn pour la souplesse de développement que ca offre plus que pour la gestion des branches SVN. Ils n'ont toujours pas le droit de merger dans le trunk ou dans les branches de release. Par contre ils ont bien compris que les branches SVN et des branches locales rendaient *leur* travail plus facile... On a que du Linux en station aussi.
[^] # Re: git-svn n'est pas parfait
Posté par Ju. . Évalué à 1.
Son approche est interessante
http://unethicalblogger.com/posts/2008/10/git_back_subversio(...)
le truc vraiment malin est d'utiliser hudson pour tout automatiser, du coup le vers est dans le fruit et tu peux profiter d'hudson pour ajouter des 'metriques' genre le -lint de ton language, et lancer les tests unitaires, PMD etc...
J'ai pas teste mais vu que j'ai la meme problematique au boulot, tout retour est bienvenu
# Migration SVN => Git
Posté par Ludo . Évalué à 5.
On n'a rien perdu, pas même les noms des committeurs.
# Git sous Windows
Posté par tanguy_k (site web personnel) . Évalué à 3.
Il n'y a pas d'équivalent à TortoiseSVN qui est une vraie merveille, c'est une des raisons qui me fait préférer le developpement sous Windows.
Il existe QGit : http://digilander.libero.it/mcostalba/ mais quand j'ai testé c'était pas encore ça.
Pour Mercurial il existe TortoiseHg : http://bitbucket.org/tortoisehg/stable/wiki/Home mais j'ai jamais testé.
Vous utilisez quoi comme outils ?
[^] # Re: Git sous Windows
Posté par DjeFr . Évalué à 2.
Je ne l'ai pas encore utilisé, mais il parait que ça n'est pas aussi performant que sous unix [réf. nécessaire].
[^] # Re: Git sous Windows
Posté par tanguy_k (site web personnel) . Évalué à 2.
Ca utilise msysgit en fait, dommage qu'il n'existe pas de libgit multiplateforme, ca serait quand meme une approche bien plus "propre"
[^] # Re: Git sous Windows
Posté par Maxime (site web personnel) . Évalué à 2.
svn ci
svn add
...
Je ne connais Tortoise que de nom, qu'est-ce qu'il pourrait m'apporter de + selon toi ?
[^] # Re: Git sous Windows
Posté par CrEv (site web personnel) . Évalué à 2.
[^] # Re: Git sous Windows
Posté par grid . Évalué à 4.
En plus, c'est intégré à visual studio.
[^] # Re: Git sous Windows
Posté par tanguy_k (site web personnel) . Évalué à 2.
Tortoise affiche alors une fenetre (cf http://tortoisegit.googlecode.com/files/commit.jpg )
Je peux verifier mon commit, selectionner-deselectionner les fichiers à commiter, voir et modifier les diff de facon graphique...
Quand j'ecris le message de commit, il me corrige les fautes, reconnait les mots contenus dans les fichiers qui vont etre commités (auto-completion sur les noms de classes). On peut voir et utiliser les messages des anciens commits.
C'est bien plus pratique qu'un 'svn diff' avant de commiter et ca permet d'etre sur de son commit et de pas faire de conneries. Pour ma part, je trouve ca tout simplement INDISPENSABLE :)
[^] # Re: Git sous Windows
Posté par thedude . Évalué à 1.
Je sais pas quel est l'integration dans Visual Studio, mais etant rompu a eclipse depuis qq annees, le concept meme de tortoise me depasse.
Bon, apres, tout le monde ne fait pas du Java ou autre language decemment supporte par eclipse, donc heureusement que ca existe pour les autres.
[^] # Re: Git sous Windows
Posté par CrEv (site web personnel) . Évalué à 3.
A priori c'est quand même du niveau de git (du même niveau quoi) mais avec de meilleurs outils pour windows / eclipse (important pour moi)
Du moment que les fonctionnalités sont là ;)
(sous linux uniquement j'utiliserais git)
A priori par contre il existe plusieurs interfaces à svn, contrairement à git
[^] # Re: Git sous Windows
Posté par Nicolas (site web personnel) . Évalué à 0.
[^] # Re: Git sous Windows
Posté par ckyl . Évalué à 1.
Ici beaucoup utilisaient subclipse, tout ceux qui sont passé à git ont dégagé jgit très rapidement.
[^] # Re: Git sous Windows
Posté par Littleboy . Évalué à 4.
Encore pas mal de boulot en perspective, mais c'est deja ca. En tout cas c'est toujours mieux que le client "graphique" inclus avec msysgit, auquel il manque l'option git-pull (apparemment c'est pas utile pour le dev principal... gni?).
En fait le gros probleme avec git, c'est que c'est ecrit par des mecs surement tres cales au niveau programmation, mais qui n'en ont rien a foutre de l'integration avec quoi que ce soit d'autre. Et contrairement a d'autres projets, on a pas encore vraiment d'equipe qui soit prete a reprendre le code upstream pour en faire quelque chose d'utilisable par un etre humain normalement constitue...
# svn-merge
Posté par Thomas Petazzoni (site web personnel) . Évalué à 1.
- utiliser le script svn-merge.py avec les versions de SVN < 1.5. Ce script note dans une propriété SVN quelles révisions ont été mergées, et peut donc déduire automatiquement ce qui reste à merger. Il gère aussi très bien le problème du cherry-picking ou de l'exclusion de certaines révisions qu'on ne veut pas merger.
- depuis SVN 1.5, le merge tracking a été intégré officiellement. Il fonctionne apparemment sur le même principe que svn-merge.py, mais je n'ai jamais eu l'occasion de l'utiliser.
[^] # Re: svn-merge
Posté par CrEv (site web personnel) . Évalué à 2.
mais franchement le merge c'est pas encore ça
Le cherry picking ça marche encore assez bien, mais le merge de branches ... non
Dès que les branches sont un peu trop vieilles c'est toujours galère
En plus, le problème d'svn est qu'on perd complètement l'historique de merge
Si je merge une branche dans une autre, j'applique en fait localement les commits de la branche à merger dans la copie de la branche de destination.
Je gère les conflits, toussa, et ensuite je commit
Mais voilà, le merge est finalement _un_ commit
Si je n'indique pas en commentaire tout ce qui est fait dans mon commit, les révisions mergés par exemple, ben c'est perdu
J'ai aussi rencontré plusieurs fois des problèmes sur un svn merge --reintegrate (alors que c'est le but, que ça marche sans se poser de question...)
Pour le moment, un collègue utilise git-svn pour ses branches (enfin depuis 2 jours)
Moi j'ai aussi essayé mercurial mais sans vraiment de succès pour la gestion svn, mais je vais continuer dans se sens dans l'espoir d'avoir un truc vraiment intégré à windows, eclipse, linux, etc
on verra bien ce que ça donne
Mais l'approche décentralisée apporte des choses intéressantes, surtout si on prend l'habitude de faire des branches, même locales, pour tout ce qu'on fait. Ca permet de vraiment bien organiser les choses, mais aussi le développeur ne peu plus dire "désolé je suis en train de tout refactorisé, j'en ai pour 2 jours sans commiter et ton problème ben on verra plus tard" dans ce cas ce serait dans une branche, un problème arrive ? on change vite fait de branche, le travail commencé n'est pas perdu, on peut développer plusieurs choses en parallèle !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.