Ça faisait un moment que je voulais regarder git, histoire de ne pas mourir idiot, et bien que je n'apprécie pas du tout les DVCS (j'y reviens). Mais bon, quand on voit que dès qu'un projet commence, une des premières requêtes est : "why not git?" si le projet utilise un bon vieux Subversion, je me dis que ça ne vaut pas le coup de perdre du temps à argumenter et démarrer directement par git (oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouve). Donc voilà, je vais d'abord vous dire pourquoi je n'aime pas les DVCS (Distributed Version Control System), donc git en particulier, et au final, ce que j'aime dans git après avoir lu pas mal de tuto et fait quelques expériences.
Tout d'abord, je pense que les DVCS induisent un comportement malsain en terme de développement par rapport au VCS genre Subversion. C'est une thèse que je tiens depuis un moment (j'ai la flemme d'aller rechercher dans mes anciens commentaires mais j'ai déjà dû y faire allusion ici même). Pourquoi ? Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCS.
Version longue : je nuance. Il existe des workflows avec un DVCS qui ne sont pas très satisfaisants pour un développement open-source. Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert. Je ne dis pas que tout le monde fait ça, je dis que c'est un comportement possible. C'est un peu comme en C, on peut faire n'importe quoi, mais on peut aussi très bien s'en servir.
Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être. Alors après, oui, on peut très bien avoir un workflows plus ouvert, et les sites tels github ou gitorious aide aussi énormément à cela. Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ? Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste.
Maintenant, certains me vanteront les avantages techniques, et me diront que c'est un super outil, toussa toussa. Mais ce que je veux dire là n'a rien de technique, c'est plus une raison philosophique qui me pousse à fuir les DVCS.
Mais bon, comme je l'ai dit, je ne veux pas mourir idiot et à l'occasion d'une idée de projet que je commence, je me suis dit : essayons. Alors, j'ai commencé à lire quelques tutoriels pour git, de qualité assez inégale. J'ai d'abord lu Git - SVN Crash Course qui permet à des gens habitués à SVN de se familiariser avec Git. Je dois dire que c'était assez obscur à la sortie et qu'il me restait plein de zones d'ombre sur la manière dont git fonctionne. J'ai jeté un oeil à gittutorial(7) mais je dois dire que j'ai vite abandonné, vu la rapidité des explications. J'ai continué avec Git Reference (écrit par les gars de github) et là, ça a éclairé ma lanterne mieux que tous les autres réunis. Je trouve les explications bien faites, progressive, didactique, avec des exemples simples mais éclairants. Donc je conseille ce dernier à tous ceux qui veulent s'y mettre.
Du coup, maintenant que j'ai une assez bonne idée de git et de son fonctionnement, voilà ce que je trouve sympa dans git. Tout d'abord, cette idée d'avoir une "staging area" (concept totalement inconnu dans SVN, lisez Git Reference pour comprendre ce que c'est) qui permet de sélectionner les fichiers à commiter et les autres. Je me suis retrouvé si souvent dans cette situation avec Subversion où je ne voulais commiter qu'une partie des fichiers modifiés et que je ne pouvais pas, à moins de pratiquer des acrobaties.
Ensuite, j'aime bien la manière de gérer les changements de nom de fichier comme n'étant justement pas un changement de nom (puisqu'en fait, ce ne sont pas les fichiers qui sont versionnés mais leur contenu). Je ne me suis pas risqué à faire quelques tests un peu tordus mais je me demande ce qu'il se passe si on a un gros fichier plein de code et qu'on le coupe en deux fichiers, est-ce que git est capable de repérer la source commune pour ces deux fichiers ? En tout cas, si c'est le cas, j'aime encore plus cette fonctionnalité.
Enfin, j'aime bien la gestion simplifié des branches et de les voir comme des contextes de travail plutôt que comme des trucs lourds auxquels on ne touche plus une fois que la branche est crée (rares sont les branches mergées dans Subversion, ça tient en partie à la difficulté technique de merger mais aussi au ressenti des développeurs avec l'utilisation des branches). Ici, avec git, pas de problème, on saute de branche en branche.
On sent bien qu'avec git, on peut procéder de 40 manières différentes pour le worflow. Je pense que c'est ce qui fait sa force. Mais sa faiblesse également selon moi. En tout cas, je vais continuer à l'utiliser pour mon projet, histoire de voir si à l'usage, ça marche. Jusqu'à présent, j'ai surtout essayé de comprendre le fonctionnement et je vais passer à l'utilisation dans un cas réel. Je reviendrai peut-être te revoir, cher journal, pour partager cette expérience.
Journal Git malgré moi
24
sept.
2010
# Mon ressentit
Posté par blobmaster . Évalué à 8.
C'est fou mais mon ressenti depuis 2 ans que j'utilise mercurial c'est que c'est totalement le contraire.
Je dirais même que l'un des problèmes du passage au DVCS c'est d'obliger ceux qui ont l'habitude de juste pousser bêtement à réfléchir pendant leur merge sur la place de leur code par rapport à celui des autres.
Je trouve que les DVCS (mercurial dans mon experience) donne plus de visibilité sur le code des autres que les VCS (CVS SVN Clearcase dans mon experience).
[^] # Re: Mon ressentit
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: Mon ressentit
Posté par Corentin Chary (site web personnel) . Évalué à 4.
Ton dépôt git perso ne sera qu'un dépôt de travail, le vrai dépôt important, c'est celui upstream.
[^] # Re: Mon ressentit
Posté par Brioche4012 (site web personnel) . Évalué à 4.
Je suis plutot un utilisateur de bazaar, mais ce que je trouve bien, c'est que le developeur peut bosser sur sa feature en commitant souvent (je commite frequemment) en local, puis une fois que c'est bien teste et bien fini, hop, on fait une demande de pull.
Il faut bien voir que SVN n'a toujours pas de commits locaux, donc si on fait une connerie, on n'a plus qu'a revenir a la version du repo...
[^] # Re: Mon ressentit
Posté par El Titi . Évalué à 4.
Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc.
Ce n'est pas le rôle du VCS mais du bugtracker ou de la forge de faciliter cette communication.
S'il est centralisé, on sait qui a pris quoi, à quoi est dédiée telle branche.
J'entends souvent l'objection que tu évoques à savoir ce risque d'isolation qui fait que SVN colle si bien à l'intégration continue i.e à l'usage d'un branche unique.
Et pourtant la CI n'est pas l'apanage des outils centralisés.
Je te conseille cet excellent papier de Martin Fowler sur le sujet
http://martinfowler.com/bliki/FeatureBranch.html
En revanche, ce qui est sûr c'est qu'un outil comme SVN qui est incapable de supporter le "rename tracking" correctement (renommer un fichier différemment entre 2 branches perd l'historique de ce fichier lors du prochain merge entre ces 2 branches) ne peut supporter que l'integration continue et les branching par patch (une branche par patch que l'on tue une foi integrée).
Pas de salut pour les autres branching patterns (1 branche par developpeur , une par lot de fonctionnalité en vue d'un développement parallèle de plusieurs équipes avec une phase d'intégration avant la livraison, ...)
De là à dire que la mode de la CI n'existe que parce que SVN est déficient à la base, il n'y a qu'un pas.
# Mercurial.
Posté par Yth (Mastodon) . Évalué à 8.
je ne connais pas git, mais j'utilise Mercurial avec un grand plaisir depuis quelques temps déjà.
J'ai "compris" Mercurial grâce à ce petit tutoriel, qui pourrait t'aider aussi avec git, en sachant que les commandes ne sont pas les mêmes, mais que les fonctionnalités se recoupent.
http://hginit.com/
Et franchement, après quelques mois d'être passé de SVN à Mercurial, jamais jamais je ne reviendrai en arrière, tout est bien plus simple avec Mercurial, j'adore !
Yth.
# Re: Git malgré moi
Posté par j_kerviel . Évalué à 7.
Merci pour ce retour, très intéressant pour un utilisateur occasionnel (et grand fan) de git comme moi.
La seconde partie, surtout, apporte des informations très intéressantes.
Par contre sur la première partie, j'ai peur de ne pas être tout à fait d'accord avec toi.
oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouveFranchement ce n'est pas vraiment étonnant.Il est plus simple de dire "pourquoi tu commences avec SVN alors que tu peux avoir quelque chose de mille fois plus puissant et performant avec GIT ?" plutôt que "pourquoi tu veux utiliser GIT ? Utilise un truc qui fait moins de choses, parce que... heu parce que tu es habitué et parce que tout le monde a toujours fait comme ça" (argument de Windowsien quoi).
On a beau être vendredi, je ne trolle qu'à moitié.
Dans mon ancienne boite, où je militais activement (mais sans plus, je ne suis qu'administrateur système, pas développeur, c'est leur problème s'ils ne choisissent pas les bons outils) pour un passage de SVN à GIT, le lead dev m'a opposé un argument imparable : "Ouais, mais GIT, ce n'est pas très connu, je ne sais pas si on peu vraiment s'y fier, alors que SVN, ça a fait ses preuves sur des gros projets comme apache et ses millions de lignes de code". J'ai beaucoup rigolé, et je crois que je ne l'ai jamais dit pourquoi sa réflexion était ridicule.
Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCSJe ne comprends pas bien l'argumentation là.Tu es en train de dire que l'utilisation d'un outil distribué va à l'encontre du partage ?
On pourrait dire la même chose de la plupart des licences libres, copyleft ou pas. N'importe qui peut récupérer la source en local et ne pas contribuer upstream. Heureusement qu'on a l'aGPL, dans ce cas.
Et puis je ne suis pas très à l'aise avec la thèse disant que les DVCS seraient "malsains" parce qu'ils offrent plus de liberté à l'utilisateur (dont, cette soit disant liberté d'être plus individualiste qu'avec SVN, ce dont je ne suis pas du tout convaincu).
Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert.Et qu'est ce qui empêche de faire la même chose avec svn (un checkout et travailler en local ensuite) ?Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être.Non, la raison d'être, c'est de permettre de cloner un repo facilement. C'est la raison d'être du logiciel libre. Si c'est libre mais qu'en pratique on ne peut pas forker, à quoi sert la liberté ?En pratique, ça permet des choses comme les sous systèmes dans linux : Linus ne pull que parmi les branches de personnes de confiance, eux même prennent leurs commits depuis des personnes à qui ils délèguent leur confiance. On a ainsi une cathédrale de confiance redoutablement efficace.
Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ?Je ne vois pas le rapport.Combien de projets "imposent" SVN en ne fournissant pas de tarball ? Combien de projets versionnés par SVN proposent de taper deux lignes pour récupérer les sources et aucun autre moyen de le faire ?
En soi, ce n'est pas grave. Mais en entreprise, derrière certains firewalls fascistes, ça rend les choses très compliquées et c'est relativement frustrant.
Bref, sur ce point là, GIT ou SVN, même combat. Dans les deux cas, rien n'empêche de fournir un tarball des sources sur un serveur http.
Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste.Je pense que tes conclusions sont un peu hatives :)(version édulcorée de "foutaises")
Bonne continuation avec git. Vivement ton prochain feedback.
[^] # Re: Git malgré moi
Posté par rewind (Mastodon) . Évalué à 2.
- l'argument "c'est plus répandu donc c'est mieux", je le bannis directement, c'est un argument d'autorité, je suis un scientifique, on me convainct mieux avec des arguments scientifiques. Donc, là, je suis d'accord avec toi (et pas d'accord avec ton lead dev).
- je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. Tout comme le C peut induire des comportements de codage dangereux, ça ne veut pas dire que le C est dangereux ou que le C va à l'encontre de la sécurité. Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.
- le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par git.
Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ? Parce que selon les tutos, il y a la méthode "je crée une branche par grosse fonctionnalité", ou alors "je crée une branche quand j'ai un développement qui va vraiment diverger". Quels sont les bonnes pratiques en la matière ?
[^] # Re: Git malgré moi
Posté par Mildred (site web personnel) . Évalué à 4.
Tu crée une branche quand tu clone.
Ensuite, je travaille sur un bout de code. Si je l'ai fini, je le push sur master, sinon, il reste en attente en local (avec un push éventuel sur une branche distante "username-fonctionnalité" pour que les autres puissent voir ce que je fais.
Si je n'ai pas fini cette fonctionnalité et que je dois travailler sur utre chose (par exemple j'ai besoin de corriger un bug, ou je pense à une toute autre fonctionnalité), alors je vais faire une branche locale supplémentaire du master distant. Et ainsi de suite.
Donc, en pratique je fais une branche à chaque fois que je fais quelque chose de non trivial qui peut mettre du temps à finir ou mettre du temps à être accepté.
[^] # Re: Git malgré moi
Posté par j_kerviel . Évalué à 8.
- je ne dis pas qu'un outil distribué va à l'encontre du partage, je ne dis pas que c'est malsain, je dis que ça peut induire des comportements malsain. [...] Tu vois ce que je veux dire ? Et c'est cette possibilité qui me chagrine et que je trouve assez absente des VCS. Mais après, je peux me tromper et avoir une mauvaise vision.Je ne me permettrais pas de dire que tu te trompes, ce serait pédant et subjectif. Mais je n'arrive vraiment pas à comprendre pourquoi tu considères que les DVCS permettent plus facilement de copier du code et de le conserver en local que ne le ferait SVN ou même un tarball.
En quoi le fait que ça passe par git, svn, wget, scp rsync ou autre chose change la donne ?
Mais après, je peux me tromper et avoir une mauvaise vision.Disons que nos visions divergent. Après dire qu'une vision est bonne ou mauvaise, le bien le mal, le manichéisme toussa, ça ne me semble pas pertinent dans un échange prolifique entre deux personnes sensées.le workflow de Linux est certes exemplaire, mais ce n'est qu'un exemple de workflow parmi tout ceux proposés par gitC'est justement toute la beauté de git. Avec git, tu peux faire un workflow svn. Mais il en existe beaucoup d'autres.
C'est aussi pour ça que j'aime git.
Puisque je te tiens, je vais te poser une question purement pratique : quand créer une branche ?Bonne question :)
Je me la suis également longtemps posée. Et comme je manque de créativité et que j'ai eu la chance de tomber sur un article[1] fort sympathique sur identica (via le groupe !git), je m'en suis inspiré.
Le problème, c'est que c'est plutôt orienté pour les gros projets. Moi je ne suis qu'un petit développeur du dimanche (mais enthousiaste).
Mais ce n'est pas tant un problème que ça. Il suffit de picorer dedans et de prendre ce qui est nécessaire ou pas. Du moins c'est comme ça que je procède.
Selon le projet, je ne fais pas toujours de branches (autres que la principale bien sûr), parfois j'y ajoute juste une branche de développement. Parfois une branche pour une feature, si je sais que ça va mettre un certain nombre de temps à développer et que je ferais d'autre release entre temps.
Bref, je pense que ce document peut servir de référence, qu'il est tout à fait adapté pour les gros projets, et adaptable pour les plus petits projets.
C'est aussi ce qui peux expliquer que tu ait pu voir plusieurs méthodes différentes. Chacun a une expérience différente en fonction des projets différents. Mais je pense aussi (et je peux me tromper), que plus le projet grossit, plus le modèle de développement tend vers quelque chose de similaire, l'exemple le plus abouti étant Linux.
En espérant que ça d'aide au moins un peu.
[1] http://nvie.com/posts/a-successful-git-branching-model/
(Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).
[^] # Re: Git malgré moi
Posté par rewind (Mastodon) . Évalué à 4.
>> (Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).
Ça m'aurait ennuyé que tu répondes en 140 caractères...
[^] # Re: Git malgré moi
Posté par rewind (Mastodon) . Évalué à 2.
Sinon, ça donne des idées d'organisation. Merci beaucoup.
La seule chose que je n'ai pas compris, c'est qu'il utilise --no-ff. Je vois vraiment pas l'intérêt. Est-ce qu'il ne perd pas toutes les micros étapes qu'il a fait dans la branche ? Du coup, quel intérêt de bien découper en micro étape (en plus, il insiste pour bien séparer) si tous les commits sont regroupés en un seul dans sa branche develop et qu'il supprime sa branche feature ? Bref, soit il y a qqch que je n'ai pas bien compris, soit il explique mal, soit il fait un truc idiot.
[^] # Re: Git malgré moi
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Git malgré moi
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: Git malgré moi
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Git malgré moi
Posté par rewind (Mastodon) . Évalué à 3.
[^] # Re: Git malgré moi
Posté par El Titi . Évalué à 3.
Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.
Je m'explique:
Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.
Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.
Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.
En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.
Ce workflow est plus complexe mais plus souple.
C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.
Voilà je crains avoir encore plus délayé que toi.
[^] # Re: Git malgré moi
Posté par El Titi . Évalué à 1.
du problème:
http://subversion.tigris.org/issues/show_bug.cgi?id=898
Etant donné que SVN utilise svn cp pour brancher et ne fait sémantiquement pas la différence entre une branche et une simple copie d'arbo ce problème n'est pas près d'être résolu. Les branches sont des objets à part entières dans Git
Quelque commentaires:
"""
Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
renames branch, it won't be merged before 1.3.
...
Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
move to 1.8-consider.
...
Seems like this thing is going to be pushed out indefinitely.
"""
Ce bug a été ouvert en 2002 et il est reporté aux calendes grecques.
Nous en sommes à la 1.6.12.
Bonne chance les gars
[^] # Re: Git malgré moi
Posté par Alban Crequy (site web personnel) . Évalué à 1.
Je crée une branche tout le temps. Aucun commit ne se fait directement dans master. Les commits qui sont sur master sont ceux qui ont été relu par un autre membre de l'équipe de développement. Si j'ai un mini patch de quelques lignes, ça se passe comme ça:
- je mets le commit dans une branche publique nommée "typo" ou qqch comme ça
- je demande une relecture sur IRC
- on me repond "ok"
- je merge dans master
Que ce soit juste un mini patch ou une branche contenant des dizaines de patches, le processus revient au même. Bien sûr, il est plus facile de trouver quelqu'un pour relire la branche quand la branche ne contient pas 100 patches non-nettoyés (c'est à dire que des commits contiennent des "printf" temporaires de debug). Il est d'usage de découper la branche en patches par fonctionnalité avant de la proposer à la relecture.
Ça c'est pour les branches publiques qu'on propose à la relecture. Ensuite, j'ai des branches privées temporaires, lorsque je rebase (git-rebase roxor), j'expérimente quelque chose qui n'aboutit à rien. Dans ce cas, comment j'organise mon travail n'est pas très important. Tout comme si j'utilise emacs, gedit ou vim n'a pas d'importance sur le projet.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Git svn
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Git svn
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: Git svn
Posté par Gabin . Évalué à 2.
[^] # Re: Git svn
Posté par ckyl . Évalué à 3.
Tu as la puissance de git en local tout en ayant la possibilité de garder ton repo SVN et donc n'avoir rien à changer dans tes confs et pour les autres. C'est très très très pratique quand tu es dans une infrastructure assez lourde et que tu ne peux pas changer de SCM facilement (Au choix problème de gestion, management, technique, formation des autres devs, manque d'outils etc.).
Tout les devs avec qui j'ai bossé et qui ont essayé ne peuvent plus s'en passer tellement ca leur facilite la vie. Pourtant ils étaient tous sceptiques.
Workflow commun:
- Ton master local correspond au trunk/
- Possibilité de mapper des branches locales vers des branches subversion. On créé une branche par feature. Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
- Pour les petits patchs solo, une branche locale (aussi rattachée au trunk) un dcommit et c'est poussé dans le trunk.
Après ca reste git, compliqué d'accès. Trop de choix et de facon de faire. Marrant presque aucuns de ceux qui utilise git-svn ne l'utilisent de la même facon (merge puis dcommit VS dcommit, rebase VS merge, suivi de branch). Bref chacun fait a sa sauce, ce qui implique de perdre pas mal de temps au départ et n'aide pas à son adoption.
Bref c'est l'outil idéal si comme contrainte tu as "Le dépot du projet sur lequel je bosse est SVN". Attention j'ai pas dit que c'était l'outil idéal ;-)
[^] # Re: Git svn
Posté par Gabin . Évalué à 0.
- Ton master local correspond au trunk/
ça ok
- Possibilité de mapper des branches locales vers des branches subversion.
L'intérêt? Pourquoi ne pas fait directement une branche dans svn?
On créé une branche par feature.
C'est pas un peu abusé du concept, juste un point de vue.
Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
Encore une fois, qu'est-ce qui empêche de créer une branche svn à part?
À te lire, on a l'impression que les autres devs n'y ont pas accès
Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
Tu fais ton "merge" dans GIT et tu synchronises ensuite dans le tronc SVN?
Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
[^] # Re: Git svn
Posté par ckyl . Évalué à 3.
En fait c'est mal exprimé en effet. Tu crée ta branche subversion et tu peux associé N de tes branches git à cette branche subversion. En général une seule suffit, mais des fois c'est pratique d'en faire deux. Pour bosser sur des trucs séparés qui iront dans la même branche SVN. Évidement l'intêret de la branche SVN, c'est que les gens qui utilisent SVN peuvent y avoir accès.
Note que tu gardes le côté pratique de git, par ce qu'un commit git n'entraine pas immédiatement un commit SVN. Tu décides quand les pousser.
> C'est pas un peu abusé du concept, juste un point de vue.
C'est un point de vue en effet. Libre à chacun de faire comme il le veut. L'expérience m'a montré que mettre de nouveaux devs ou des refactoring important dans le trunk était une très mauvaise idée. Tu te retrouves avec un trunk non stable, ou avec des fonctionalités que tu ne veux pas encore ds la branche officielle donc impossibilité de releaser (voir même souvent de rollbacker). Avoir une branche par feature ca permet de prendre son temps pour que tout arrive à maturation, et de réfléchir au moment où tu intègres dans la branche principale. Ne pas créer de branche, ca veut dire que quelqu'un bosse en sousmarin donc tu n'as aucune idée de son changeset. C'est une question d'équilibre c'est sur. Il n'y a pas de bonne solution, il y a des solutions qui fonctionne avec ton projet et ton équipe.
> À te lire, on a l'impression que les autres devs n'y ont pas accès
Si bien sur, c'est une branche SVN. Ce que t'apporte git-svn, ce sont les branches locales et la possibilité créer une ou plusieurs branches git à partir d'une branche SVN. Tu travailles en locale avec tes branches git. Et tu pousses tes commits sur le SVN en une commande, de même tu mets à jour en une commande. Bref tu as la puissance de git sur la gestion des branches, des merges, des cherry-pick, du stash etc. tout en utilisant très simplement SVN. Hormis 2 ou 3 pièges ca fonctionne très bien, j'ai jamais réussi à le planter.
> Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
Oui c'est un des gros interet de passer à git-svn. Les merge (ou rebase) sont fait par git. Ensuite tu pousses le résultat sur le SVN. L'inconvéniant c'est que à cause du backend SVN tu perds les informations de merge dans git une fois que c'est poussé. Y'a pas de miracle.
> Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
La j'ai pas compris la question.
Pour résumé comme dit plus haut. git-svn c'est le meilleur client svn, même si tu veux pas merger.
[^] # Re: Git svn
Posté par Alban Crequy (site web personnel) . Évalué à 1.
L'intérêt? Pourquoi ne pas fait directement une branche dans svn?
Quand je développe une nouvelle fonctionnalité non triviale (disons 5 patches), je n'écris pas directement les 5 patches du premier coup directement sans erreur. J'expérimente quelque chose, je me rends compte que ce que j'écris n'est pas la meilleur solution, je change en cours de route. Je teste, il y a un bug dans le deuxième patch, je le corrige. Bref, pendant ce processus, j'ai besoin de modifier le deuxième patch sur les 5 commits en local. Puis je me rends compte que le troisième patch contient des debugs que je ne voulais pas commiter, et une faute de grammaire dans les commentaires. Je corrige. Ensuite, je propose mes 5 patches propres à la relecture, ils sont approuvés, puis inclus dans master.
Si j'avais fait tout cela avec svn, j'aurais eu deux possibilités:
- soit je propose un seul patch contenant l'équivalent de mes 5 patches. Ça va être plus difficile au relecteur de comprendre et d'être sûr qu'il n'y a pas d'erreur car on perd le découpage en patches élémentaires.
- soit je commit au fur et à mesure mes patches dans la branche svn. Mais toujours pareil, le relecteur doit se taper les erreurs de développement. Ça lui fait du travail supplémentaire. Le temps du relecteur n'est pas une ressource illimité, il risque de ne pas avoir le temps et de ne pas accepter mon travail.
Et puis personnellement, même si je propose un seul patch sur svn, git reste un bon outil pour moi pour conserver mes patches d'expérimentation, y revenir, etc. On ne peut pas faire ça avec svn. Quilt est pas mal pour ça, mais l'interface de git est tout de même meilleure et plus simple.
# staging area
Posté par Antoine . Évalué à 4.
Il suffit de passer explicitement la liste des fichiers (ou des répertoires) derrière "svn ci". Loin de moi l'idée de défendre SVN en général face aux DVCS, mais ici je ne vois pas où est l'acrobatie ni la difficulté.
[^] # Re: staging area
Posté par enzbang (site web personnel) . Évalué à 3.
[^] # Re: staging area
Posté par Mildred (site web personnel) . Évalué à 3.
[^] # Re: staging area
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: staging area
Posté par Mildred (site web personnel) . Évalué à 1.
tu fais ton refactoring avec comme message "refactoring"
tu finis ta fonctionnalité "temp2"
et tu fais un rebase intéractif: git rebase -i HEAD~5
tu déplace tes commits pour avoir:
pick refactoring
pick temp1
squash temp2
Les deux derniers commits seront fusionnés et on te demandera le nouveau message de commit.
http://book.git-scm.com/4_interactive_rebasing.html
[^] # Re: staging area
Posté par MrLapinot (site web personnel) . Évalué à 6.
[^] # Re: staging area
Posté par El Titi . Évalué à 2.
http://svnbook.red-bean.com/en/1.5/svn.advanced.changelists.(...)
Ceci permet de regrouper les changements à commiter.
Le mécanisme n'est pas aussi puissant que la mise en place de branches dédiées (inhérent aux DVCS) qui permet de commiter les changements de manière unitaire puis de reporter ceux que l'on souhaite sur le tronc (cherry-picking). D'ailleurs, si quelqu'un a déjà pu utiliser le cherry-picking correctement avec SVN, je suis preneur pour un retour d'expérience.
[^] # Re: staging area
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: staging area
Posté par El Titi . Évalué à 3.
[^] # Re: staging area
Posté par rewind (Mastodon) . Évalué à 4.
[^] # Re: staging area
Posté par El Titi . Évalué à 2.
Cette belle idée au départ de pouvoir brancher à plat directement dans l'arborescence couplée avec cette notion de révisions qui simule des "liens symboliques" et qui pointe que sur les fichiers modifiés depuis la dernière révision était séduisante. (branche et tags en O(n)). L'équipe SVN s'était dit qu'ils s'occuperaient des branches plus tard (mémoire de merge, rename tracking, pas de merge cycliques, ... par exemple) et dans les faits c'est tout qui est à revoir. (pour le rename tracking il faut des identifiants d'objet alors qu'on a que des révsions ou un DAG+notion de branche pour être efficace). Leur modèle se complique (mergeinfo qu'il faut supprimer à la main, révisions à indiquer explicitement parce la mémoire de merge est défaillante, option reintegrate pour traiter les branches de patch, ...) Ils sont dans une impasse ... Ca explique pourquoi on trouve ca dans la section advanced.
http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Du coup on conseille de bosser dans une branche et on promeut l'intégration continue puisqu'on ne sait traiter que ça.
[^] # Re: staging area
Posté par Antoine . Évalué à 1.
svn di > travailencours.patch
svn revert -R .
# faire le refactoring
svn ci -m "Refactoring"
patch -p0 < travailencours.patch
# reprendre le travail précédent
# Un bon VCS est un DVCS
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
En effet, lorsqu'on modifie des documents, avec un VCS décentralisé, on a le choix entre :
— commiter au fur et à mesure, donc des versions non fonctionnelles ;
— ne commiter que lorsqu'on a fini chaque travail, donc des versions censées être fonctionnelles.
La première solution est une mauvaise idée dans le cadre d'un travail en équipe. La seconde solution revient à travailler sans filet entre chaque étape, et amène souvent à gérer son travail avec le bon vieux outil de gestion de version cp-old (cp fichier fichier.old). Ce qui, quand on dispose d'un vrai outil de gestion de version, est quand même un comble !
[^] # Re: Un bon VCS est un DVCS
Posté par Georges Dubus (site web personnel) . Évalué à 2.
Après, il y a des outils comme quilt out stgit qui permettent de faciliter ce fonctionnement encore plus.
[^] # Re: Un bon VCS est un DVCS
Posté par pasScott pasForstall . Évalué à -1.
Après, ca veut pas dire que les dvcs n'ont pas leur gros avantages sur les centralises, mais on peut tout a fait s'en sortir avec svn. C'est juste plus chiant dans certains cas.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Un bon VCS est un DVCS
Posté par Philippe F (site web personnel) . Évalué à 2.
Avec un DVCS, les membres ont tendance à garder pour eux leurs développement en cours, et à faire des push moins souvent qu'ils ne faisaient de commits. Du coup, on a des périodes où tout le monde bosse sur un truc, mais ce n'est pas visible sur le dépot principal.
[^] # Re: Un bon VCS est un DVCS
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
[^] # Re: Un bon VCS est un DVCS
Posté par rewind (Mastodon) . Évalué à 1.
# workflows
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
> mainteneur est pour moi une manière de faire très peu en adéquation avec un
> développement ouvert.
Tu proposes quoi comme alternative avec un VCS centralisé ? J'en vois deux :
1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.
Pour la version 1), je ne sais pas si ça t'es déjà arrivé d'être autorisé à commiter sur le SVN d'un projet avant d'avoir fait tes preuves avec du code, mais perso, ça ne m'est jamais arrivé, même en rêve. Maintenant, admettons que ça arrive. Cool, je peux commiter sur le dépôt, je n'ai même pas besoin de parler du code sur la mailing-list avant de commiter. C'est plutôt un handicap pour le côté communautaire, non, de pouvoir commiter sans discuter ?
Reste la solution 2), et c'est justement là qu'un DVCS est infiniment plus puissant/pratique, puisque tu peux faire tes commits en local, donc gérer assez facilement plusieurs patchs (y compris si les patchs dépendent les uns des autres).
Le fait qu'on puisse cloner un dépôt est justement quelque chose qui force un fonctionnement communautaire. Avec un VCS centralisé, tu as en général une short-list de gens qui ont les droits pour les commits, et le fait que techniquement ils aient ce droit leur donne un très grand pouvoir de décision. Les gens qui ne sont pas sur la short-list sont mis à l'écart. Avec un DVCS, tu peux aussi avoir un petit nombre de gens qui ont accès au dépôt de référence (éventuellement, ce petit nombre peut être 1), mais si ils abusent de leur pouvoir, les autres contributeurs peuvent continuer à travailler et à s'organiser. Un corolaire est que les mainteneurs n'abusent pas de leurs pouvoir pour les projets gérés par un DVCS.
> Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web
> (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un
> développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et
> l'abandonne au bon vouloir.
Quelle différence avec un SVN accessible en lecture seule, publié et abandonné au bon vouloir ?
[^] # Re: workflows
Posté par ckyl . Évalué à 3.
>1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
>2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.
3) Je sais configurer mon VCS, alors je donne les droits d'écriture aux wannabes qui le demande uniquement sur une branche qui leur est dédiée. Comme ca je peux voir leur travail en cours de route et les aider. Et c'est moi qui merge leurs commits dans les branches de prod.
[^] # Re: workflows
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Moi, ce que je vois autour de moi, c'est qu'il faut galérer à envoyer des patchs avec un outil qui le fait mal pendant un moment avant d'avoir ça.
[^] # Re: workflows
Posté par ckyl . Évalué à 2.
Je crois que dans le libre, les gens préfèrent leur confort et leurs convictions à aider les autres à intégrer un projet. On essaye encore de te convaincre sur quel éditeur utiliser en 2010... ;) Mais y'a des projets très sympas où le maintainer est très acceuillant pour ceux qui cherchent à contribuer. Récuperer un commit bit sur hudson c'est pas trop compliqué par exemple.
[^] # Re: workflows
Posté par tesiruna . Évalué à 2.
gère ça très bien.
Par exemple avec svn si tu ne notes pas les commits que t'as mergé de telle ou
telle branche tu ne t'en sors pas.
[^] # Re: workflows
Posté par rewind (Mastodon) . Évalué à 3.
[1] http://developer.kde.org/documentation/other/developer-faq.h(...)
[^] # Re: workflows
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them.
Maintenant, faudrait que tu nous expliques ce que tu entends par « forker dans son coin ». Ce que permet un DVCS, c'est d'avoir des branches qui sont hébergées ailleurs que sur le dépôt principal. Ça change quoi que mes branches soient hébergées sur mon site perso, sur github, ou dans l'archive du projet ? Ce qui est important, c'est de savoir quel code est dans la branche principale (i.e. le trunk sous SVN), mais imposer à tout le monde d'héberger ses branches au même endroit, je vois pas l'intérêt.
Ce qui fait que les gens poussent d'une manière ou d'une autre leur code en upstream, ce n'est pas l'outil, c'est pour les 1001 raisons qui font que l'open-source marche. La gloire d'avoir du code à soi en upstream, le fait de ne pas avoir à maintenir une branch séparée longtemps, ...
Avec SVN, tu peux forker sans problème. svnsync par exemple te permet même de récupérer l'historique. Côté « fork », les VCS sont à peu près tous à égalité. Le problème, c'est le merge qui peut suivre le fork.
Ce qui est marrant, c'est qu'ailleurs, tu dis que le workflow de Linux est exemplaire, et justement, le workflow de Linux, c'est exactement ce que tu as l'air de critiquer ici.
[^] # Re: workflows
Posté par rewind (Mastodon) . Évalué à 3.
Ensuite, dans la phrase que tu cites, il y a exactement ce que je décris dans mon texte initial : avec un VCS, le gars qui fait des modifs est obligé de discuter avec upstream, il est obligé de s'intégrer socialement avec le projet, il est obligé de collaborer s'il veut que ses modifs soient intégrées, parce qu'il est relativement difficile de maintenir un patch en dehors de la "branche principale" (parce que justement, ce n'est pas fait pour ça). Alors qu'un DVCS, tu peux avoir ton fork sur ton site, sans en parler à upstream. Ce que ça change (puisque c'est ta question), c'est que dans un cas, tu as une obligation technique de collaborer, dans l'autre cas, tu as une permission technique de ne pas collaborer. Et ma thèse, c'est que ça peut engendrer des comportements idoines, en ce sens qu'avec un DVCS, tu peux faire ton égoiste dans ton coin, chose impossible avec un VCS. Et j'insiste bien sur "peux", parce qu'effectivement, on peut faire autrement aussi et ça se passe bien dans la plupart des cas (heureusement).
Quant à Linux, ce n'est pas un workflow où chacun garde tout dans son coin sur son site, c'est un workflow assez complexe et très hiérarchique où tout est public, au vu et au su de tous. Donc ça ne rentre vraiment pas dans le comportement que je critique. Et d'ailleurs, ceux qui s'y essaient dans le développement de Linux se font taper sur les doigts (comme Google récemment). Ce qui n'est pas imposé par le VCS l'est par la communauté. Il n'y a qu'à voir la procédure d'acception des patchs où un des premiers trucs qui est dit est : en parler sur la LKML, c'est à dire s'intégrer socialement avec le projet, et la boucle est bouclée.
# Les DVCS encouragent le travail collaboratif
Posté par GeneralZod . Évalué à 3.
Un DVCS permet le travail hors-ligne (le développeur a toujours accès à l'historique, peut commiter les modifications ==> gros avantage pour le travail collaboratif), des opérations beaucoup plus rapides car moins d'accès réseau, pour un outil aussi utilisé qu'un VCS c'est très important. La gestion des branches permet aux développeurs d'expérimenter plus facilement sans perturber le développement de la branche principale, de gérer différentes versions d'un même logiciel plus facilement (avec le cherry-picking/transplant, porter un bugfix deviendrait presque trivial), l'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Sans oublier la souplesse des DVCS qui facilitent leur intégration dans les workflows (et notamment les outils de revue, la possibilité d'importer/exporter des patchs via mail sans perdre l'historique etc ...).
===> Git ou mercurial sont de bien meilleurs VCS que ne le sont CVS ou svn (et comme j'aime le répéter le meilleur client subversion s'appelle git ;-) )
Rien n'est plus faux que d'affirmer qu'un DVCS encourage le travail isolé, je dirais que c'est même le contraire. Par rapport à CVS (et dans une moindre mesure svn), git/hg permettent de s'abstraire des défauts de ces outils (accès réseau obligatoire, lenteurs, merge pourri, gestion des branches complexes, outils fragiles).
[^] # Re: Les DVCS encouragent le travail collaboratif
Posté par El Titi . Évalué à 3.
L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.
SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.
Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.
La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).
# DCVS vs CVS centralisés
Posté par barmic . Évalué à 6.
Si ce soir j'ai une super idée pour améliorer un projet X utilisant subversion :
- je checkout les sources
- je code
- je génère un patch
- j'envois mon patch à la liste de diffusion (je ne suis pas commiter du projet)
Maintenant je veux faire la même chose avec le projet Y qui lui utilise un DCVS quelconque :
- je clone le dépôt
- je code (avec la possibilité de faire des commit locaux, des branches etc...)
- je génère un patch que j'envoie sur le ML ou je fait un merge request en expliquant clairement mon code (je ne suis pas commiter donc pas de pull)
Que ce soit l'un ou l'autre, si tu n'a pas les droits tu es obligé d'expliquer ce que tu fait et si tu as les droits rien ne t'empêche de ne rien dire à personne. Je ne vois vraiment pas ce qui change dans la manière de faire.
Évidement l'exemple du dessus prend en compte que tu as un dépôt centrale qui fait office d'upstream. Je n'ai encore jamais vu de projet qui n'en n'avaient pas et je pense sincèrement qu'un projet qui ce constitue sur un réseau de dépôt non hiérarchisé ne tiendras pas plus de quelques développeurs sans voler en éclat.
Note : tu as svk qui permet de faire du DCVS avec du subversion.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: DCVS vs CVS centralisés
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: DCVS vs CVS centralisés
Posté par barmic . Évalué à 1.
Si tu regarde le workflow du kernel c'est très différent de ce qu'on fait avec un CVS centralisé et pourtant magie, ils ont un dépôt de référence.
On peut inverser ton raisonnement et dire que quelque soit l'outil si tu l'utilise mal tu as une probabilité importante de faire de la merde, je suis d'accord avec toi.
Après c'est comme tout se fermer des fonctionnalités sous prétexte que ça peut être mal utilisé c'est vraiment dommage surtout que dans notre cas celui qui décide a probablement une influence importante dans le choix du workflow.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: DCVS vs CVS centralisés
Posté par rewind (Mastodon) . Évalué à 0.
Bref, pour répondre à ta première question, je vais t'en poser une autre : tu as des exemples concrets de programme en C avec des memory leaks ?
[^] # Re: DCVS vs CVS centralisés
Posté par barmic . Évalué à 6.
subversion n'a jamais empêché qui que ce soit de faire un fork, mais de ce que j'ai crus comprendre ce qui te gène c'est la possibilité de pouvoir faire un pull d'un dépot différent de celui où on fait un push car ça faciliterais le maintient d'une version alternative du logiciel ?
Je ne vois pas cela comme un mal ça peut simplifier le maintient de logiciel comme Iceweasel par exemple.
D'une manière générale, je pense qu'il est mauvais de croire qu'un problème « social » peut être résolu par la technique. Ça me semble illusoire et ça peut toujours être contrecarré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: DCVS vs CVS centralisés
Posté par rewind (Mastodon) . Évalué à 3.
En quelque sorte, oui.
>> D'une manière générale, je pense qu'il est mauvais de croire qu'un problème « social » peut être résolu par la technique. Ça me semble illusoire et ça peut toujours être contrecarré.
Et pourtant, avec notre OS préféré (que ce soit BSD ou Linux d'ailleurs), nous sommes entourés de mesures techniques qui règlent des problèmes sociaux. Ne serait-ce que l'existence de droits, et du compte root, "pour pas que les utilisateurs normaux fassent n'importe quoi", alors que c'est juste pour empêcher qu'ils puissent faire n'importe quoi, qu'ils en aient la possibilité. Et oui, ça peut être contourné et même des gens s'y emploient à longueur de journée. N'empêche que ça marche bien la plupart du temps.
[^] # Re: DCVS vs CVS centralisés
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.