Le code source de Darcs 2.2pre2 est disponible en téléchargement [1].
Par rapport à la version 2.1.2 sortie novembre dernier, cette version apporte peu de changements visibles à l'utilisateur. Hormis les corrections de bogues et les améliorations de performance, le plus gros du travail a porté sur la simplification du code et sa portabilité.
Entre temps, il y a eu également un changement important: le concepteur initial David Roundy a laissé sa place au très impliqué Eric Kow [2], et le développement de darcs a eu un coup de fouet grace au Hacking Sprint de fin octobre [3] (un prochain est prévu en mars). Les développeurs impliqués poussent pour que darcs soit mieux modularisé, et réutilise des modules développés par la communauté Haskell. La version 2.2 est l'occasion de sortir une version préliminaire de libdarcs afin d'encourager des projets d'interface graphique se greffant dessus.
darcs est un système de gestion de version distribué, comme git et mercurial donc. Mais il est le seul à gérer les patchs de manière non chronologique, ce qui permet d'échanger librement des patchs indépendants entre dépots, comme le montre cette vidéo [4]. Par conséquent, son utilisation nécessite d'apprendre moins de concepts que git ou mercurial.
Pour les gens qui connaissent les déboires que darcs a eu depuis ses débuts, sachez que les plus gros problèmes furent réglés lors de la version 2 sortie l'année dernière [5]. Cependant, darcs reste largement moins performant que ses homologues plus connus, et n'est donc pas recommandé pour gérer un gros projet, ou un projet contenant des fichiers binaires.
[1] http://lists.osuosl.org/pipermail/darcs-users/2009-January/0(...)
[2] http://lists.osuosl.org/pipermail/darcs-users/2008-November/(...)
[3] http://blog.codersbase.com/2008/10/28/darcs-hacking-sprint-s(...)
[4] http://projects.haskell.org/camp/unique
[5] http://mark.stosberg.com/blog/2008/10/darcs-2-a-major-update(...)
Journal Darcs 2.2 release candidate
11
jan.
2009
# sale temps
Posté par Troy McClure (site web personnel) . Évalué à 7.
En plus j'ai moyennement confiance dans les kernel hackers pour faire des outils simples et ergonomiques, git est certainement le plus performant, mais l'approche "couteau suisse" linux-centric, avec 10000 options pour power users ne m'enchante pas plus que ça.
[^] # Re: sale temps
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Si git est bien mais trop complexe pour satisfaire tout le monde, alors il n'y a pas de raisons que les autres solutions tombent dans l'oublie.
Dans le libre si une solution tombe dans l'oublie, c'est que personne n'en avais plus besoin, il n'y a donc aucun regret, d'autant que si le besoin réapparaît ne serait-ce que chez un seul utilisateur il pourra regagner en vigueur.
[^] # Re: sale temps
Posté par vieuxshell (site web personnel) . Évalué à 5.
Pas exactement, si une solution tombe c'est qu'il n'y a plus personne pour la maintenir. Il peut rester des utilisateurs (même nombreux parfois) qui s'il n'ont pas l'argent/te temps/la motivation/la compétence se retrouvent "coincés".
[^] # Re: sale temps
Posté par psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: sale temps
Posté par Bozo_le_clown . Évalué à 4.
Sors de ce corps !!!!!!!
[^] # Re: sale temps
Posté par vieuxshell (site web personnel) . Évalué à 4.
Mais le libre c'est comme le libéralisme, c'est pas parce que la régulation est théoriquement possible sans intervention (et que ca marche parfois) que ca se vérifie toujours en pratique.
On peut faire un logiciel libre de merde, on peut faire un virus libre, on peut "planter" une petite communauté de non techniciens voire de non librisites en ne maintenant plus une application.
[^] # Re: sale temps
Posté par psychoslave__ (site web personnel) . Évalué à 0.
C'est sûr qu'un développeur peu arrêter développer son logiciel libre, mais les utilisateurs ne se retrouvent pas le bec dans l'eau : soit ils ont du temps et la volonté de se retrousser les manches, soit ils paient quelqu'un pour leur fournir du support.
Si la communauté d'utilisateur dont tu parles ne sont prêt ni à l'un ni à l'autre, c'est qu'il ne méritent pas d'utiliser ce logiciel libre et qu'en fait ils ne sont qu'un attroupement de rapaces qui attendent qu'on leur donne tout sans qu'ils n'apportent rien.
[^] # Re: sale temps
Posté par vieuxshell (site web personnel) . Évalué à 2.
Dans le logiciel libre, on est également libre de ne pas participer au développement ;)
Il peut également se trouver des cas ou l'on a pas la possibilité ni technique, ni financière de faire réaliser le travail. En plus je ne suis pas certain qu'il soit facile de trouver une personne pour "coder le truc" pour pas trop cher (15,20,50 euros). Et si tu fais appel à une SSLL, la note ne vas pas être la même...
[^] # Re: sale temps
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je suis d'accord qu'il peu arriver des moment où l'on a pas les moyens, comme le l'ai dit plus haut il se peu que «tu manques momentanément de moyens pour avancer, mais rien ne t'empêche de t'organiser pour te donner ces moyens».
Personnellement, je ne considère pas ça comme un mur infranchissable, tout au plus comme un obstacle plus ou moins difficile à passer sur le parcours.
Après chacun son opinion, je ne sais pas si ce qui m'a valut d'être moinsé c'est mon opinion lui même ou le ton avec lequel je l'ai exprimé, mais j'aurais bien aimé plus d'arguments des détracteurs de l'hypothèse que je soutiens.
Donc merci pour ta réponse, même si elle n'abonde pas en mon sens.
[^] # Re: sale temps
Posté par vieuxshell (site web personnel) . Évalué à 2.
Pour ma part, je préfere largement un logiciel libre non maintenu qu'un logiciel propriétaire en fin de vie (avec les $$ qui vont bien à l'éditeur pour qu'il daigne nous permettre d'utiliser un vieux produit buggé qu'il ne support plus).
C'est d'ailleurs plus simple en entreprise que pour un particulier. Une entreprise peut facilement engager un sous-traitant ou une SSLL pour maintenir un soft libre qui n'a plus d'upstream. Par contre, pour les particuliers, ils faut quand même une dose de chance à mon avis (trouver un dev qui accepte de le faire, à moindre coût ou gratuitement).
D'ailleurs je ne crois pas qu'il existe un système genre "Perdu de recherche" où une communauté en perdition peut appeler Supercoder pour les sauver en échange d'un slip propre.
[^] # Re: sale temps
Posté par ribwund . Évalué à 2.
[^] # Re: sale temps
Posté par Temsa (site web personnel) . Évalué à 7.
Devant travailler couramment (voire la plupart du temps) sous windows, j'echangerai volontier mes 50 svn contre des mercurial (et c'est d'ailleurs en cours :P ), qui plus est les plugins mercurial pour les ide sont bien plus mature sur mercurial que sur git à ma connaissance (c'est même fourni par défaut dans netbeans).
Bref, je suis très loin de partager ton avis sur "git prend tout" !
Par contre concernant darcs, je souhaite qu'il continue à vivre, néanmoins je n'en ai pas l'utilité, j'espère qu'il trouvera son public :)
[^] # Re: sale temps
Posté par Clément David (site web personnel) . Évalué à 0.
C'est ce qui fait la puissance de git à mon avis, on le considère comme une spécification avant de choisir un client. Vivement l'intégration de ces nouveaux clients dans les IDEs ( [http://git.or.cz/gitwiki/EclipsePlugin] et [http://code.google.com/p/nbgit/] ) .
[^] # Re: sale temps
Posté par ribwund . Évalué à 3.
Sinon le thread qui tourne actuellement sur la ml de mercurial est assez interessant (sur l'interoperabilité hg/git).
http://article.gmane.org/gmane.comp.version-control.mercuria(...)
[^] # Re: sale temps
Posté par Troy McClure (site web personnel) . Évalué à 3.
En particulier le dernier paragraphe de http://article.gmane.org/gmane.comp.version-control.mercuria(...) (sur le non-merge de mercurial avec bzr) est assez instructif
[^] # Re: sale temps
Posté par ribwund . Évalué à 3.
[^] # Re: sale temps
Posté par Bozo_le_clown . Évalué à -1.
Le transfert de copyright existe sur nombre de soft (Java et Sun me semble t'il) sur les sources et personne ne trouve à redire.
On voit le pb qu'il advient dans le cas contraire avec Linux pour le passage en GPL v3
Sinon tu es au courant aussi que la grande majorité des devs d'Eclipse core sont des devs d'IBM mais ca ne te choque pas
Donc c'est quoi exactement le risque ?
Ah oui Canonical le demande pour faire des extensions proprio.
le demandait semble t'il ? "A few years ago".
Il parait que Sun ne voulait pas entendre parler de Java Opensource il y a quelques années et aujourd'hui toute leur stratégie est axée dessus.
Bref si c'est pas du FUD ca !
[^] # Re: sale temps
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: sale temps
Posté par Bozo_le_clown . Évalué à 2.
Il n'empêche que ce changement de license n'est pas possible du fait qu'il faut demander l'avis de tous les auteurs (y compris ceux qu'on ne peut joindre)
Ca serait aller vers une BSD, le pb serait le même.
[^] # Re: sale temps
Posté par ribwund . Évalué à 2.
Donc c'est quoi exactement le risque ?
Le risque c'est que Canonical décide un jour d'arrêter de financer bzr (comme tla/baz à l'époque) et que comme tous les developpeurs principaux sont employés par Canonical, le support deviennent inexistant.
C'est ce qui s'est passé pour baz, Canonical avait repris baz, puis forké sur bzr tout en promettant de continuer à maintenir le projet. Au final ils ont jamais rien fait sur baz, considérant bzr comme plus crucial.
Pour Canonical, launchpad étant la pièce maitresse de leur business modele, on peut imaginer que si git devient *le* DSCM de réference ils soient obligés d'y passer, dans ce cas les ressources de bzr risquent de passer entierement sur launchpad+git le business primant sur le reste.
Du point de vue des licences ça dépend des opinions, disont que certaines personnes ont été échaudés par l'épisode bitkeeper ("open" source, puis entierement propriétaire avec des licences bien restrictives) pour preferer empêcher tout fork propriétaire du logiciel. Je ne pense pas que ce soit dans l'avantage de Canonical de mettre un terme au developpement open source de bzr, mais le risque est non nul (un rachat ou une faillite dans quelques années est-il totalement improbable ?).
[^] # Re: sale temps
Posté par Bozo_le_clown . Évalué à 3.
C'est le risque pour tout projet libre dans lequel une société s'implique.
(Les devs IBM d'Eclipse sont maintenant affectés au projet Jazz)
Si le projet meurt c'est simplement qu'il n'était pas viable et ne correspondait pas à une attente. S'il a du potentiel,il sera repris.
PAr ailleurs un projet abouti , n'a pas forcément besoin qu'on lui alloue autant de ressources (C'est ainsi qu'IBM justifie la réaffectation de ses devs)
pour preferer empêcher tout fork propriétaire du logiciel.
Un fork propriétaire n'enlève rien au fait que la version opensource peut continuer d'exister.
Sourceforge a forké en proprio et est passé de PHP à Java . C'est ainsi et c'est le jeu.
[^] # Re: sale temps
Posté par Bozo_le_clown . Évalué à 1.
Du point de vue des licences ça dépend des opinions, disont que certaines personnes ont été échaudés par l'épisode bitkeeper ("open" source, puis entiérement propriétaire avec des licences bien restrictives)
Bitkeeper n'a jamais été opensource. Il était gratuit pour ces projets et à changé sa politique.
http://fr.wikipedia.org/wiki/BitKeeper
Bazaar est un projet GNU sous licence GPL.
[^] # Re: sale temps
Posté par ribwund . Évalué à 2.
[^] # Re: sale temps
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.