Articles précédents : Logiciel
- [7] Correction grammaticale dans OpenOffice.org
- [30] CDs de jeux libres LanPower
- [18] X-Moto 0.4.2 est sorti
- [40] Nagios 3.0
- [4] OW2 EasyBeans 1.0 RC 3
- [36] Mythtv 0.21
- [66] GNOME Scan 0.6 : vulgariser la numérisation
- [151] GNOME 2.22 : évolution perpétuelle
- [65] Schrödinger 1.0 : le codec Dirac est prêt
- [4] La solution documentaire Quotero publie ses sources
Liens connexes
- Bazaar (690 hits)
- ChangeLog de la version 1.3 (183 hits)
- Bazaar devient un projet GNU (198 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Nouvelle version de Bazaar, le DVCS de Canonical
Posté par TeXitoi (Jabber id, page perso, ). Modéré le 20 mars 2008.
C'est la première version depuis que Bazaar est devenu un projet GNU le 26 février.
![[en]](../../../images/en.png)
Bazaar (690 hits)-
ChangeLog de la version 1.3 (183 hits)
-
Bazaar devient un projet GNU (198 hits)
> Lire la dépêche (54 commentaires, moyenne: 3,4).
- Ê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.
Emacs et bzr
A noter qu'Emacs est en train de migrer vers bzr.
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 ;-).
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Matthieu C () le 20/03/2008 à 19:59. (lien). Évalué à 7.plus d'info sur http://lwn.net/Articles/272853/
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...[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Plop () le 20/03/2008 à 22:07. (lien). Évalué à 10.Je crois qu'il est temps de changer GNU/RMS par un bot plus performant.
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par JB. Giraudeau (Jabber id, page perso, ) le 21/03/2008 à 08:29. (lien). Évalué à 10.Pour résumer ce qu'a dit RMS à ce sujet:
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.
--
"ça dépend du type de workload, si tu est CPU-bound ça va mieux qu'en memory-bound, où les access patterns et la corrélation des paquets peut avoir des effets non linéaires sur le wallclock time[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par CrEv (page perso, ) le 21/03/2008 à 09:06. (lien). Évalué à 8.GNU is an operating system project.
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)[ Répondre ]
-
[+] [^]Re: Emacs et bzr
Posté par kaouete (page perso, ) le 21/03/2008 à 09:37. (lien). Évalué à -5.Oui en même temps, l'élitisme c'est sympa, mais c'est pas grâce à lui que les humains ont évolués (d'un point de vue physique autant que d'un point de vue moral).
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 !)[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par √λιi () le 21/03/2008 à 09:55. (lien). Évalué à 7.Je comprend pas trop ce laïus sur l'élitisme alors que le logiciel libre repose entièrement sur la philosophie hacker, ou la méritocratie gouverne.
Or si la méritocratie n'est pas un système élitiste, je mange mon chapeau.[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Sylvain Sauvage () le 21/03/2008 à 13:03. (lien). Évalué à 1.Ben, le système élitiste, c’est l’aristocratie : étymologiquement « gouvernement des meilleurs » en grec…
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par √λιi () le 21/03/2008 à 14:00. (lien). Évalué à 3.Tu peux dire que la méritocratie est une aristocratie si ca te chante. Mais tu risques de ne pas être très bien compris. Le mot aristocratie a un peu dévié de son sens étymologique.
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Sylvain Sauvage () le 22/03/2008 à 14:59. (lien). Évalué à 8.Bon, faut que j’arrête avec les points de suspension, personne ne comprend qu’ils indiquent qu’il faut creuser. Alors je développe :
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…[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par wilk (Jabber id, page perso, ) le 22/03/2008 à 21:13. (lien). Évalué à 4.La différence de taille c'est que le programmeur méritocrate n'a de pouvoir que sur ce qu'il fait alors que l'aristocrate a un pouvoir sur ce qui ne le concerne pas.
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 ;-)[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Thomas Douillard () le 23/03/2008 à 14:15. (lien). Évalué à 3.Pas vraiment, le fork en lui même ne donne aucun pouvoir dans un sens : essaye de forker Linux, tu auras du mal à avoir autant de pouvoir qu'un Torvalds ... sauf à avoir les épaules pour rerentrer dans le système, ou a déjà avoir le pouvoir d'un IBM ou d'un Microsoft ...
[ Répondre ]
-
[^]Re: Emacs et bzr
-
-
-
-
-
-
[^]Re: Emacs et bzr
Posté par kaouete (page perso, ) le 21/03/2008 à 14:06. (lien). Évalué à 3.Heh bien je me suis un peu emmêlé les pinceaux dans mes idées il semblerait :]
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 :)[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par √λιi () le 21/03/2008 à 14:30. (lien). Évalué à 4.Oui mais non :)
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 :)[ Répondre ]
-
-
-
[^]Re: Emacs et bzr
Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 21/03/2008 à 19:21. (lien). Évalué à 1.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.
Ouais, d'ailleurs, la démocratie a amené Sarkozy. Ça c'est un progrès intéressant \o/--
[ Répondre ] Ce commentaire est-il impertinent ou utile ?[ Répondre ]
-
-
[^]Re: Emacs et bzr
Posté par rewind () le 21/03/2008 à 10:14. (lien). Évalué à 6.pourquoi scinder le monde en deux ? C'est parce que c'est à la mode ? Torvalds comme tu dis est plutôt "Open Source", ça ne l'a pas empêché de mettre Linux sous GPL. Et je suis persuadé qu'en cherchant un peu, on peut trouver l'inverse.
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).[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par CrEv (page perso, ) le 21/03/2008 à 10:34. (lien). Évalué à 3.(petite perte de mon commentaire suite à une erreur mysql...)
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.[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par gentildemon () le 21/03/2008 à 11:13. (lien). Évalué à 10.Bof, je trouve pas ça idiot.
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.[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par champi () le 21/03/2008 à 12:24. (lien). Évalué à 1.D'autant plus que choisir bzr, git ou hg n'est pas non plus un choix grave, car ils ont tout trois un jeu de plugins qui s'enrichit de jour en jour et des models compatibles ce qui laisse penser que dans le futur on aura une interoperabilité totale entre les trois et que chaque développeur pourra choisir l'outil qui lui plait le mieux sans que ca gene les autres.
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par paul () le 21/03/2008 à 20:27. (lien). Évalué à 7.L'article de LWN ne reflète pas l'ambiance de la ML. Stallman n'écoute pas l'opinion des développeurs et choisi pour eux l'outil qu'ils devront utiliser. Certains sont vraiment vexés, car cette procédure donne l'impression qu'on est juste une force de travail pour un projet qu'on ne maîtrise pas un brin. Donc,
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.--
paul[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par boklm (page perso, ) le 21/03/2008 à 22:46. (lien). Évalué à 2.C'est deja amusant qu'il ait fini pas accepter de passer à un autre gestionnaire de version que CVS.
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(...)[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par TeXitoi (Jabber id, page perso, ) le 22/03/2008 à 12:20. (lien). Évalué à 2.Il serait possible d'avoir la source pour cette histoire de 1 à 1000. Je veux bien le croire, mais ca me semble beaucoup, quand même.
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Bruno Michel (Jabber id, page perso, ) le 22/03/2008 à 16:14. (lien). Évalué à 4.http://article.gmane.org/gmane.comp.version-control.bazaar-n(...)
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
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par wilk (Jabber id, page perso, ) le 22/03/2008 à 21:25. (lien). Évalué à 3.L'auteur a rectifié par la suite :
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.[ Répondre ]
-
-
-
-
-
-
-
-
[^]Re: Emacs et bzr
Posté par GeneralZod () le 21/03/2008 à 09:33. (lien). Évalué à 7.En même temps, il est paradoxal que RMS choisisse un DVCS maintenue par une société qu'il critique pour maintenir une distribution non-libre.
http://thomas.apestaart.org/gallery/main.php?g2_itemId=14498[ Répondre ]
-
[^]Re: Emacs et bzr
-
-
[+] [^]Re: Emacs et bzr
Posté par Bonnefille Guilhem (page perso, ) le 21/03/2008 à 10:12. (lien). Évalué à -1.<troll mode="combat">
Peut-on en déduire que Hurd va passer sous Bazaar ?
</troll>
:-)
:-)
C'est vendredi...
Ok, je sors --->[][ Répondre ]
-
[^]Re: Emacs et bzr
Posté par JB. Giraudeau (Jabber id, page perso, ) le 21/03/2008 à 13:19. (lien). Évalué à 1.C'est en tout cas ce que RMS semble implicitement recommander.
(que tout les projet GNU utilise le dvcs GNU, si ils doivent en utiliser un)--
"ça dépend du type de workload, si tu est CPU-bound ça va mieux qu'en memory-bound, où les access patterns et la corrélation des paquets peut avoir des effets non linéaires sur le wallclock time[ Répondre ]
-
-
[^]Re: Emacs et bzr
Posté par paul () le 21/03/2008 à 20:13. (lien). Évalué à 3.Sauf que RMS a semblé oublier que les développeurs d'emacs ne sont pas forcément férus de GNU. Ils veulent pouvoir hacker emacs dans de bonnes conditions, avec un logiciel libre.
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.--
paul[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Gniarf () le 22/03/2008 à 00:49. (lien). Évalué à 1.ben c'est à dire que en même temps on ne peut pas être développeur emacs - ni même utilisateur emacs - sans sentir la présence du bonhomme pas loin derrière. ou lui tout court. sans être obligé de finir féru de GNU et de RMS, en résumé.
--
Windows has no users. It has hostages.[ Répondre ]
-
-
[^]Re: Emacs et bzr
Posté par fleny68 () le 22/03/2008 à 08:51. (lien). Évalué à 2.Est-ce que Python est un projet GNU ?
Parce qu'un logiciel GNU qui dépend d'un pas GNU, ça risque de pas le faire.[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Spyhawk () le 22/03/2008 à 09:42. (lien). Évalué à 2.Ah ouai.. dans le même genre que le Kernel Linux ? :)
[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par fleny68 () le 22/03/2008 à 12:33. (lien). Évalué à 2.Il y a un projet GNU pour remplacer le noyau Linux. The Hurd, ça s'appelle.
http://www.gnu.org/software/hurd/hurd.html[ Répondre ]
-
[^]Re: Emacs et bzr
Posté par Matthieu C () le 22/03/2008 à 18:27. (lien). Évalué à 4.Oui et j'espère que bzr ne suivra pas le même chemin que hurd.
[ Répondre ]
-
-
-
-
-
-
-
[^]Re: Emacs et bzr
Qui utilise bzr ?
Moi je l'utilise aussi bien pour les développement de code (dans le cadre d'abinit (http://www.abinit.org)) que pour collaborer avec des collègues sur les cours: on utilise un repository bazaar-NG par cours dans lequel se trouvent les textes des TD, corrigés, etc.
Perso je trouve ça génial. Mais le passage par "bazaar" a été un peu difficile et je ne connais rien à git ou svn...
PMA
[ Répondre ]
-
[^]Re: Qui utilise bzr ?
Posté par gS () le 21/03/2008 à 09:07. (lien). Évalué à 4.Nous l'utilisons aussi dans ma boite.
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.[ Répondre ]
-
[^]Re: Qui utilise bzr ?
Posté par wilk (Jabber id, page perso, ) le 22/03/2008 à 21:41. (lien). Évalué à 1.Je l'utilise pour tous mes devs pro ou perso.
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.[ Répondre ]
Copyright Canonical ou FSF ?
> "sous copyright de Canonical (licence GPL)"
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."
[ Répondre ]
Comment faire du développement dans l'industrie avec SGVD ?
Bon c'est un petit peu hors sujet et en plus c'est un copié collé d'un commentaire que j'ai posté dans le Journal de NoNo et qui n'a pas eu réponse, j'espère que vous m'en excuserez.
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.
[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS () le 21/03/2008 à 18:28. (lien). Évalué à 3.Chez nous le passage de CVS s'est fait sans douleur. Nous étions habituée a avoir un serveur central, une branche de dev, des branches pour les releases avec des tags (beta, rc et stables).
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).[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Bozo le clown () le 21/03/2008 à 22:37. (lien). Évalué à 3.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.
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 ?[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 22/03/2008 à 00:37. (lien). Évalué à 3.Je ne suis certes pas, de curusu, un développeur mais j'ai du mal à saisir ce qui est tellement intéressant dans les SGVD par rapport aux SGVC, à plus forte raison pour une entreprise.
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 ?[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Antoine () le 22/03/2008 à 00:58. (lien). Évalué à 1.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 ?
SVN fonctionne déjà par « changeset » sauf que le terme utilisé est révision.[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 22/03/2008 à 13:19. (lien). Évalué à 2.C'est bien ce qu'il me semblait, parce qu'il m'arrive souvent de faire un commit pour plusieurs fichiers, qui auront tous la même révision. Il est alors facile de retrouver les fichiers modifiés par cette révision.
[ Répondre ]
-
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Xavier Verne (page perso, ) le 22/03/2008 à 10:56. (lien). É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.[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par zul (Jabber id, page perso, ) le 22/03/2008 à 12:13. (lien). Évalué à 4.Je pense que Linus dans son speech pour Google a aussi cité pas mal de cas intéressant.
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, ...)[ Répondre ]
-
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS () le 25/03/2008 à 08:54. (lien). Évalué à 1.Le suivi par changeset nous facilite grandement la vie. Par exemple, en ce moment, nous finalisons une version de l'un de nos softs dans une branche. L'equipe QA nous envoie des bug reports. Nous corrigeons chacun de ces bugs et donc nous 'commitons' :) un patch, ou 'changeset' de quelques fichiers.
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.[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par imalip (page perso, ) le 25/03/2008 à 10:12. (lien). Évalué à 7.Tu vas rire, hein, mais je fais exactement la meme chose avec subversion au boulot. Les changeset et le cherrypicking n'ont rien de spécifique aux systemes distribués.
--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 25/03/2008 à 13:59. (lien). Évalué à 2.Je suis en effet d'accord avec ce constat : le cherry picking n'a rien de spécifique ni à bzr ni aux autres DCVS. Quant aux changeset, les révisions de SVN semblent répondre à peu de choses au même besoin.
[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS () le 26/03/2008 à 10:11. (lien). Évalué à 1.Nous sommes d'accord. Je tente juste une explication sur la difference entre les changesets et le systeme de revisions par fichiers.
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.[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 27/03/2008 à 11:47. (lien). Évalué à 2.Tu ne mentionnes pas SVN mais la question qui était posée et à laquelle tu réponds le mentionnait. En outre, la dernière phrase laisse penser que le « cherry picking » est l'apanage des systèmes distribués de gestions de versions alors que ce n'est pas le cas. Ensuite, entre changeset et revision, il n'y a globalement qu'une différence de noms.
[ Répondre ]
-
[^]Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS () le 28/03/2008 à 09:07. (lien). Évalué à 2.Je parle de systeme de révision *par fichier*, du type de celui présent dans CVS (il y a peut être un terme plus consacré), que nous utilisons également pour notre systeme qualité (ou chaque document est indépendant et dispose de son propre numéro de version, indépendament des autres, parfait pour la doc reglementaire).
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.[ Répondre ]
-
-
-
-
-
Cette page a été générée par Templeet en 0.1864s (dont 0.0174 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.