C'est la première version depuis que Bazaar est devenu un projet GNU le 26 février. Bazaar est un logiciel de gestion de version décentralisé qui just works. Les spécificités de Bazaar sont :
- Être facile à utiliser : l'interface est proche de celle des autres gestionnaires de versions.
- Être utilisé avec différentes organisations : Bazaar ne doit pas forcer les développeurs à une organisation donnée, mais laisse libre cours à la méthode de travail.
- Être rapide : bien que GIT et Mercurial soient encore plus rapides que Bazaar, de très grand progrès ont été faits à ce niveau. Bazaar utilise d'ailleurs depuis la version 1.0 un système de stockage proche de GIT.
- Être portable : Bazaar marche partout où python marche, c'est notamment le DVCS qui fonctionne le mieux dans un environnement MS-Windows.
- Gérer les changements de noms de fichiers et de répertoires explicitement.
Aller plus loin
- Bazaar (6 clics)
- ChangeLog de la version 1.3 (2 clics)
- Bazaar devient un projet GNU (3 clics)
# Emacs et bzr
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
http://thread.gmane.org/gmane.emacs.devel/90798/focus=91834
Et ça s'est un peu fighté sur les mailing-lists de Bazaar et Emacs à partir du moment où les gens ont comparé les performances de bzr avec celles de git (par exemple, "bzr log" met 1 minute avant de commencer à afficher le log sur une machine moderne).
Bon troll, c'est bientôt vendredi ;-).
[^] # Re: Emacs et bzr
Posté par M . Évalué à 7.
Apparemment Bazaar a été choisi par rms car c'est un projet GNU, pas parce que c'est celui qui répond le mieux au cahier des charges...
[^] # Re: Emacs et bzr
Posté par Putifuto . Évalué à 10.
[^] # Re: Emacs et bzr
Posté par JB. Giraudeau . Évalué à 10.
GNU est un projet d'un système d'exploitation libre et visant une certaine cohéance. Il est donc normal qu'un projet GNU choisisse des outils faisant partie du projet GNU, lorsque plusieurs alternatives libres et matures existent.
Le fait qu'au niveau des performances / de la popularité, bzr ne fasse pas course en tête ne doit pas influer sur le choix.
(d'ailleurs faire des comparaison exaustive des différents gestionnaires de version prendrait des semaines/années)
Cela doit au contraire pousser à adopter ce logiciel pour l'améliorer et le diffuser auprès des autres projets GNU.
pour citer RMS:
GNU is not just a label. GNU is an operating system project.
Therefore, it is our policy that GNU package maintainers
should support other GNU packages when there is a good
opportunity to do so.
This is our policy. You don't have to like it.
[^] # Re: Emacs et bzr
Posté par CrEv (site web personnel) . Évalué à 8.
Faudrait insister un peu plus sur "project" hein... parce que bon pour le moment, c'est pas trop operating leur système...
(en plus sérieux, ça montre bien la différence entre Torvalds et autres Open Sources qui choisissent la solution sur des critères technologiques et RMS et autres GPL qui choisissent sur des critères politiques)
[^] # Re: Emacs et bzr
Posté par Victor . Évalué à -5.
Je rappelle que dans l'évolution naturelle c'est pas l'élitisme qui prime, et dans la société, l'élitisme a plutôt tendance à pourrir le monde qu'a l'améliorer.
Après nous sommes dans un sous monde (les logiciels "libres" dans le monde réel), donc c'est normal que ça pose moins de problème de faire de l'élitisme, mais je suis sur qu'à faire trop d'élitisme ça finit toujours mal (NON ! VOUS N'AUREZ PAS MON POINT GODWIN !)
[^] # Re: Emacs et bzr
Posté par Anonyme . Évalué à 7.
Or si la méritocratie n'est pas un système élitiste, je mange mon chapeau.
[^] # Re: Emacs et bzr
Posté par Sylvain Sauvage . Évalué à 1.
[^] # Re: Emacs et bzr
Posté par Anonyme . Évalué à 3.
[^] # Re: Emacs et bzr
Posté par Sylvain Sauvage . Évalué à 8.
Or si la méritocratie n'est pas un système élitiste, je mange mon chapeau.
Qu’entend-t-on par méritocratie ? Que ceux qui le méritent sont ceux qui décident. Où est l’élite ? Dans la définition du mérite. Ici, ceux qui participent techniquement (dans le code) le plus, ou le mieux, ou depuis le début… C’est assez vague, hein. Enfin, bref, les « méritants » sont désignés (définis, déterminés, émergent, rétrospectivement justifiés…) par leurs capacités de codage. Donc, en résumant, l’élite des codeurs. Mouaif, ça « résume » à tout va mais on finit bien sur une prise de décision par une élite.
En français, un gouvernement par une élite, c’est une aristocratie. Alors, effectivement, le mot a plusieurs sens, notamment celui de désigner l’ensemble des aristocrates, la noblesse. En fait, c’est simplement que, à la base (Platon…), ceux qui forment l’élite dans une aristocratie, ce sont les « plus honnêtes » des citoyens. Ça a fini par faire une classe, les nobles, et on sait comment ça a fini en France : on leur coupe la tête et on en fait d’autres, tous les 50 ans… Pouf pouf, je m’égare.
Or donc, l’aristocratie, c’est une classe particulière, les « meilleurs », qui décide. Ça ne définit pas comment sont désignés les meilleurs.
Donc, oui, une « méritocratie » est un nouveau mot pour dire « aristocratie ». Un nouveau mot censé éloigner certaines connotations (à la lanterne !). Mais il n’empêche qu’il en a le sens et les inconvénients : créer une classe de dirigeants, créer des questionnements sur le mode de désignation des « meilleurs ».
C’était ça mon propos : oui, la méritocratie est un élitisme, et non, l’appeler méritocratie n’empêche pas tous les problèmes qui viennent avec un élitisme.
Remarquons que l’on peut aussi fouiller dans les autres formes de gouvernement et les comparer à cette méritocratie :
C’est aussi une forme d’oligarchie : ils ne sont pas nombreux.
C’est parfois une synarchie : ils se partagent les tâches.
Une gérontocratie : par les anciens (ont l’expérience).
Une dictature, une tyrannie ou une monarchie…
D’aucuns crieraient même parfois à la théocratie…
En tout cas, appliquée aux logiciels libres, c’est une technocratie : par les techniciens du domaine, pas par des gestionnaires qui ne connaissent rien au domaine.
Aïe, il y en a qui vont pas être contents, notamment les plus anarcho-communistes anti-mondialistes : on part d’un joli monde de bisounours où tout le monde est égal, puis certains sont « plus égaux que les autres », et on finit en, oh, quelle horreur, technocratie, vous savez, comme à Bruxelles…
[^] # Re: Emacs et bzr
Posté par wilk . Évalué à 4.
En d'autres termes, il ne faut pas confondre avoir de l'autorité et être autoritaire...
En d'autres termes informatique ça veut dire que tu peux forker.
Pour ce qui est de l'égalité c'est pareil, il ne faut pas confondre les gens sont égaux et les gens ont des droits égaux quand bien même ils seraient différents...
Qu'on retrouve également dans les logiciels libres, chacun à également le droit d'utiliser un même logiciel suivant ces préférences et non celle du développeur.
L'anarchobizounours t'embrasse ;-)
[^] # Re: Emacs et bzr
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Emacs et bzr
Posté par Moonz . Évalué à 2.
C'est d'ailleurs ce que font certaines distributions.
[^] # Re: Emacs et bzr
Posté par Victor . Évalué à 3.
Ce que je voulais faire ressortir, c'est que c'est pas parce que bzr n'est pas le *meilleur* à un moment donné qui faut le jeter (et RMS aussi :).
Mon avis est que si des gens (ici RMS) trouvent que bzr a des principes intéressant, alors ils peuvent l'adopter dans le projet GNU et l'ameliorer pour qu'il devienne le meilleur.
Et même si le logiciel libre repose sur la méritocratie, ça veut pas dire que :
1) ce sera toujours le cas
2) c'est la meilleur manière de faire
J'espère avoir mieux faire entendre mes idées :)
[^] # Re: Emacs et bzr
Posté par Anonyme . Évalué à 4.
Tu as raison de dire que si bzr n'est pas la meilleur solution actuelle, rien n'empêche qu'elle pourra être améliorée. Mais en fait, si bzn peut être amélioré, c'est qu'il peut devenir meilleur, voire la meilleure solution entre git ou mercurial.
Donc on décale le problème en un choix de "qu'est ce qui est le mieux aujourd'hui" a qu'est ce qui est le mieux pour "aujourd'hui et demain". C'est une excellente approche, mais je ne suis pas sûr que ce soit l'idée qu'RMS a derrière la tête.
Tout ceci pour retourner le trucs en répondant que "Le logiciel libre repose sur la méritocratie, ça veut dire que :"
"1) ce sera toujours le cas" parce que le hacker ne supporte pas l'idée d'utiliser un outil moins bon que l'existant, donc soit il l'utilise soit il développe un équivalent - ce qui est déjà en train de se passer avec bzr, en passant.
"2) c'est la meilleure manière de faire" parce que selon le point 1, il n'y a pas d'alternative, c'est la seule manière de faire pour le vrai hacker :)
[^] # Re: Emacs et bzr
Posté par Nicolas Schoonbroodt . Évalué à 1.
Ouais, d'ailleurs, la démocratie a amené Sarkozy. Ça c'est un progrès intéressant \o/
[^] # Re: Emacs et bzr
Posté par rewind (Mastodon) . Évalué à 6.
On peut très bien choisir la GPL et des critères technologiques ou alors la BSD et les critères politiques (les entreprises le font par exemple, elles choisissent des logiciels BSD quand ça les arrange même si ce n'est pas techniquement le meilleur logiciel derrière).
[^] # Re: Emacs et bzr
Posté par CrEv (site web personnel) . Évalué à 3.
En gros j'ai pris Torvalds et RMS pour imager simplement ma pensée. Evidemment tout ne peut pas se résumer en 2 groupes, mais ça indique tout de même deux modes de pensés différents.
En fait j'aurais du opposer libre selon l'Open Source et libre selon la FSF, ça serait peut-être plus correct (non pas dans la définition du libre, mais dans les buts de cette liberté et leurs critères)
Ce que je trouve idiot c'est que bzr soit choisit pour sur des critères politiques alors que des solutions _tout autant libre_ existent et semblent plus efficaces.
[^] # Re: Emacs et bzr
Posté par gentildemon . Évalué à 10.
Si tu lis l'article sur LWN, le résumé c'est :
1) il faut choisir un DVCS libre pour continuer le développement d'Emacs.
2) il y a trois choix possibles en gros : bzr, git, mercurial.
3) au départ, une étude doit être faite, mais le gars qui doit s'en charger est pris, et une étude ça prend du temps.
4) RMS prédit le résultat de l'étude : chacun a des avantages et des inconvénients. Tel dvcs est mieux pour ça, tel autre pour ça, etc. Au final, il y aura toujours un petit groupe pour défendre son logiciel favori. En gros, le consensus est impossible à obtenir ou va demander un temps fou. Et surtout, les 3 permettront de développer Emacs sereinement.
5) Plutôt que de troller techniquement pendant des semaines, bzr est choisi grâce au critère politique.
[^] # Re: Emacs et bzr
Posté par Olivier Grisel (site web personnel) . Évalué à 1.
[^] # Re: Emacs et bzr
Posté par paul . Évalué à 7.
1) ok; 2) y'a Darcs en haskell aussi; 3) l'étude a déjà été faite pour d'autres projets similaires, les fonctionnalités présentées sont équivalentes; 4) Ça c'est une belle démonstration de refus de débat qui est assez caractéristique à RMS. Car s'ils font la même chose, le temps nécessaire pour le faire va de 1 à 1000. En 1 c'est GIT, au milieu y'a HG, et en 1000 c'est Bzr.
Et en 5) , c'est juste pour clouer le bec à ceux qui veulent le débat.
On se demanderait presque si GIT n'aurait pas été évincé car son auteur est L.T.
[^] # Re: Emacs et bzr
Posté par Anonyme . Évalué à 2.
Au debut quand ESR a suggeré de changer de gestionnaire de version, d'avoir un bug tracker, et de poster les commits sur un chan IRC, la réponse de RMS a été qu'il n'utilise pas de browser web donc pas de bug tracker, qu'il n'est pas toujours connecté donc pas d'IRC.
http://thread.gmane.org/gmane.emacs.devel/85669
J'ai bien aimé aussi ce message :
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg024(...)
[^] # Re: Emacs et bzr
Posté par TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: Emacs et bzr
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Il semble y avoir effectivement des rapports supérieurs à 1 pour 10 000 sur certaines commandes. C'est, par exemple, le cas pour log sur les 10 ou 100 dernières révisions :
Last 100 revisions:
$ time git log -100 >/dev/null
real 0m0.011s
$ time bzr log -l100 >/dev/null
real 2m10.270s
Last 10 revisions:
$ time git log -10 >/dev/null
real 0m0.007s
$ time bzr log -l10 >/dev/null
real 2m9.163s
[^] # Re: Emacs et bzr
Posté par wilk . Évalué à 3.
http://article.gmane.org/gmane.comp.version-control.bazaar-n(...)
> Last 100 revisions:
>
> $ time git log -100 >/dev/null
> real 0m0.011s
>
> $ time bzr log -l100 >/dev/null
> real 2m10.270s
git: 0m0.009s
bzr: 0m26.562s
> Last 10 revisions:
>
> $ time git log -10 >/dev/null
> real 0m0.007s
>
> $ time bzr log -l10 >/dev/null
> real 2m9.163s
git: 0m0.005s
bzr: 0m25.519s
Ceci dit ça ne change pas le fait que le résultat est instantané ou pas.
[^] # Re: Emacs et bzr
Posté par GeneralZod . Évalué à 7.
http://thomas.apestaart.org/gallery/main.php?g2_itemId=14498
[^] # Re: Emacs et bzr
Posté par Gniarf . Évalué à 3.
[^] # Re: Emacs et bzr
Posté par Bonnefille Guilhem (site web personnel) . Évalué à -1.
Peut-on en déduire que Hurd va passer sous Bazaar ?
</troll>
:-)
:-)
C'est vendredi...
Ok, je sors --->[]
[^] # Re: Emacs et bzr
Posté par JB. Giraudeau . Évalué à 1.
(que tout les projet GNU utilise le dvcs GNU, si ils doivent en utiliser un)
[^] # Re: Emacs et bzr
Posté par paul . Évalué à 3.
Quand aux comparaisons des gestionnaires, ça ne prend pas des années lorsqu'on se limite aux critères primordiaux. Et ceux qui sont sur la ML ont vu les tests conduits sur les dépôts emacs git et bzr, c'est des chiffres, et c'est très clair. Moi qui n'ai pas un super-calculateur en guise d'ordinateur, j'aurais apprécié qu'entre deux systèmes qui présentent un facteur 1000 de différence de rapidité, le choix soit aussi technique.
[^] # Re: Emacs et bzr
Posté par Gniarf . Évalué à 1.
[^] # Re: Emacs et bzr
Posté par fleny68 . Évalué à 2.
Parce qu'un logiciel GNU qui dépend d'un pas GNU, ça risque de pas le faire.
[^] # Re: Emacs et bzr
Posté par Spyhawk . Évalué à 2.
[^] # Re: Emacs et bzr
Posté par fleny68 . Évalué à 2.
http://www.gnu.org/software/hurd/hurd.html
[^] # Re: Emacs et bzr
Posté par M . Évalué à 4.
[^] # Re: Emacs et bzr
Posté par dguihal . Évalué à 4.
~~~~~~> [] (ouf y'a du vent aujourd'hui)
# Qui utilise bzr ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
Perso je trouve ça génial. Mais le passage par "bazaar" a été un peu difficile et je ne connais rien à git ou svn...
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Qui utilise bzr ?
Posté par gS . Évalué à 4.
Nous en sommes satisfaits et les dernières versions sont bien plus rapides.
Pour la taille de notre projet, en tout cas, (+ 400K lignes, et bientôt 8000 revisions) ca fonctionne très bien.
Les versions se suivent assez rapidement, les développeurs sont très actifs. Il manque encore peut être quelques utilitaires (aussi évolués que CVSweb, par exemple) mais ça devrait arriver vite.
Les plateformes de dev sont sous Linux et Mac, mais les electroniciens l'utilisent également sous windows.
Nous en regrettons pas notre choix.
a++
Guillaume.
[^] # Re: Qui utilise bzr ?
Posté par wilk . Évalué à 1.
Même si je bosse essentiellement seul je trouve pratique de pouvoir créer des branches pour tester des nouvelles fonctionnalités et par client lorsqu'ils ont les mêmes applis mais pas aux mêmes versions.
Mais pour moi, l'intérêt de bzr en particulier est de pouvoir changer de méthode (workflow) facilement suivant si je suis connecté ou pas, si je bosse avec quelqu'un ou pas, fréquemment ou pas etc.
Par contre, c'est vrai que même pour des petits projets il reste assez poussif bien que les devs semblent s'arracher les cheveux sur ce problème depuis pas mal de temps.
# Copyright Canonical ou FSF ?
Posté par gentildemon . Évalué à 5.
il me semblait pourtant que le copyright était cédé à la FSF pour tous les projets GNU ?
> "For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you."
Après vérification sur le site de GNU [http://www.gnu.org/help/evaluation.html], ce n'est donc pas le cas!
Traduction libre : "Pour qu'un programme devienne un logiciel GNU, il n'est pas nécessaire de transférer le copyright à la FSF; c'est une question distincte. Si vous transférer le copyright à la FSF, la FSF défendra la GPL en justice si quelqu'un la viole pour votre logiciel; si vous gardez le copyright, ce sera à vous de le défendre."
# Comment faire du développement dans l'industrie avec SGVD ?
Posté par Jetto . Évalué à 1.
Il me parait évident que les outils de gestion de versions distribués sont bien plus intéressants que les outils centralisés. En plus la notion de changeset est tellement plus pertinente que le suivit des changements par fichiers que cette façon de travailler s'est imposé au outils de gestion de versions propriétaires (ClearCase UCM).
Ce qui me semble difficile à implémenter c'est un cycle de développement avec des branches/streams de développement, d'intégration, de test, de release et de maintenance.
En plus dans un environnement où à la fois Unix et Windows peut-être utilisé il n'est pas facile de choisir un outil qui convienne aux 2.
Avez vous des idées sur comment utilisé ces outils pour répondre à ces 2 contraintes?
Pour la seconde contrainte il semble que bzr soit un bon compromis.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . Évalué à 3.
Bzr peut s'utiliser de cette façon, nous avons un repository central qui comme sous CVS, contient un cerrtain nombre de branches, tags, bref, c'est la référence. Au quotidien, les devs on des checkouts fait a partir du repo central et font un 'bind' sur ce dernier.
Cela permet de faire des commits en meme temps sur sa branche locale et sur la base centrale.
C'est le meme fonctionnement que CVS, tres simple.
Si un dev travaille en déplacement ou qu'il n' a pas acces a la base centrale, il fait un unbind et bosse localement.
Lorqu'il revient, il synchronise sa branche locale avec la base centrale, on reste en permanence synchronisé avec les autres via un bzr update (comme CVS), bref tres simple, et les conflits sont notifiés et doivent êtres résolus avant de commiter.
Il arrive aussi que des devs sur des truc expérimentaux se détachent de la base centrale et ne se synchronisent qu'entre eux (un unbind pour se détacher et re-bind avec l'autre dev, c'est pratique).
Bref, je ne sais pas trop si ca répond a ta question mais c'est un exemple d'utilisation qui fonctionne très bien en entreprise (ou le cycle de dev est rigoureux, on travaille dans le biomedical).
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Bozo_le_clown . Évalué à 3.
Peux-tu préciser ta question ?
Ce que tu souhaites c'est avoir si UCM peut être mis en oeuvre avec un DVCS ou savoir quel processus appliquer pour un projet ?
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Les cas exposés par « gS » sont extrèmement révélateurs de cas particuliers. Et, pour ces cas particuliers, il faudrait revoir la base (passer d'un SGVC à un SVGD) de toute l'artillerie habituellement déployée pour conduire des projets ?
Pourtant, que ce soit avec giT ou bzr, on voit toujours revenir le principe d'un référentiel central qui, finalement, définit les sources officielles d'un projet. Les SGVD ne sont finalement que des outils facilitant les travaux dérivés ou encore trop expérimentaux pour être intégrés dans le référentiel central officiel.
Est-ce que giT, bzr ou Hg apportent plus de conforts aux développeurs que CVS ? Assurément, mais il faudra bien publier un jour ce projet, de façon officielle. Et si j'ai volontairement omis SVN, c'est parce qu'il suffit d'utiliser SVK pour obtenir un SVGD à moindre coût (par rapport à une migration vers un autre outil). Maintenant, je n'ai peut-être pas l'expérience nécessaire pour savoir si c'est un mauvais choix ou non mais je ne vois pas de raisons manifestes pour motiver un tel changement.
Par exemple : le suivi par « changeset », concrètement, ça donne quoi ? Quand est-ce un avantage par rapport à un suivi par fichier ? N'est-ce pas là une application logicielle d'une méthode de travail qu'on pourrait très bien appliquer sous SVN ?
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Antoine . Évalué à 1.
SVN fonctionne déjà par « changeset » sauf que le terme utilisé est révision.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Xavier Verne (site web personnel) . Évalué à 2.
Pourtant, que ce soit avec giT ou bzr, on voit toujours revenir le principe d'un référentiel central qui, finalement, définit les sources officielles d'un projet.
Il me semble qu'il y a deux notions mélangées : d'une part le fait qu'un projet finit par livrer une unique version à ses utilisateurs (firefox 3.0, ou bzr 1.3, etc.). Ce sont effectivement, in fine, les sources officielles du projet.
D'autre part, et c'est très différent, les modalités pour y parvenir. A ce titre, un système décentralisé peut apporter beaucoup plus de flexibilité : tests de nouvelles fonctionnalités dans une branche à part, plus de souplesse sur les modes connectés/déconnectés, et donc sur l'organisation des équipes de développeurs (extreme programming ou autre). Toutes ces choses sont possibles, mais plus difficiles à mettre en oeuvre, il me semble, via SVN et consort.
Après, clairement, dans une organisation projet informatique "traditionnelle", les développeurs ne sont pas loin géographiquement les uns des autres, le "chef de projet" est pas loin pour décider de comment faire les choses, les développeurs travaillent sur des parties assez différentes ce qui peut faciliter les "merge" sans conflit....
C'est la différence entre interface/implémentation. Le résultat c'est l'interface que tu proposes, l'API, l'implémentation c'est la manière.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par zul (site web personnel) . Évalué à 4.
Je reprends quelques points :
- dans la majorité des entreprises, avant de commiter des choses dans le dépôt central, il faut passer un tas de tests de non-regression (ce qui est long et chiant). L'effet pervers de la chose dans un système centralisé, c'est que les gens tendent à commiter d'enormes changeset à chaque fois, et pas forcement des trucs atomiques. dans un système décentralisé, tu continue de faire tes commits atomiques dans ta branche locale, et quand tu veux pusher tes changements dans le dépôt central, tu passe les tests de non-regression ( et git-bissect t'aide à retrouver pourquoi ca foire, soit dit au passage)).
- si deux développeurs travaillent sur une partie de code commun, tu peux soit créer une branche sur le dépot central (avec les problèmes que ca a, dans le namespace commun, et puis la facilité de merger des branches dans cvs/svn, n'en parlons pas), soit ils travaillent sur une branche local, et se pull/push les patchs
enfin je laisse linus faire sa pub, il est plus percutant et drole que moi.
Quand au confort d'utiliser git par rapport à cvs/svn, c'est sans commune mesure. Les opérations communes sont bien plus rapides et donc transparentes (opération de diff, opération de commit (vu que c'est local), visionnage de l'historique, merge de branches, tag, ...)
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . Évalué à 1.
Par exemple dans la branche beta, le patch 7300 corrige le bug 120 et le changeset concerne 5 fichiers.
Il est tres simple dans la branche pricipale, de demander a bzr d'appliquer juste ce patch, sans tous les précédents, ou d'appliquer une liste de patch qui modifie des fichiers qui n'ont pas trop divergés , ce qui représente la majorité des cas sur une appli de la taille de la notre (sinon, de toute façon, il faut résoudre les conflits).
Cette operation se nomme 'cherrypicking' dans le vocabulaire des systemes de gestion de version distribués et représente un progrès dans notre façon de gérer nos sources et nos versions.
a++
Guillaume.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par imalip . Évalué à 7.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . Évalué à 1.
C'est quelque chose qui peut dérouter au début et c'est une notion fondamentale.
Je n'affirme a aucun moment que seuls les systemes distribuée en sont dotés. Je ne mentionne meme pas SVN.
Je ne saisis pas pourquoi je devrais rire de mon explication.
a++
Guillaume.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . Évalué à 2.
Je conviens que ma dernière phrase pourrait être équivoque, ce n'était pas mon intention. J'essayais juste de fournir une explication qui m'aurait été utile quand je suis passé de CVS à un aute systeme.
Je ne comprends toujours pas pour quoi ca prête à rire.
a++
Guillaume.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.