Darcs est un logiciel de gestion de versions décentralisé qui, contrairement à Mercurial, Git et Bazaar, ne considère pas l'ordre chronologique des patchs présents dans un dépôt, mais calcule leurs dépendances, et permet ainsi des créations et fusions de branches très simples.
La dernière version majeure de Darcs, la 2.4, est sortie en février :
http://wiki.darcs.net/Releases/2.4
Cependant, des bogues liés à Windows ont été découverts et deux versions mineures ont dû sortir entre temps. Une nouvelle version mineure est en préparation et le projet a besoin de gens voulant bien tester sous Windows pour rapporter d'éventuels bogues. Le code source et un binaire compilé sont disponibles via cette adresse :
http://identi.ca/notice/32497686
Le moyen le plus simple de rapporter un bogue est d'envoyer une description à bugs@darcs.net .
Pour plus d'informations sur Darcs, vous pouvez consulter le wiki, notamment les sections le comparant avec les autres logiciels de gestion de versions :
http://wiki.darcs.net/
http://wiki.darcs.net/DifferencesFromOtherDVCS
http://wiki.darcs.net/DifferencesFromSubversionCVS
Merci !
Journal Appel aux testeurs Windows pour Darcs 2.4.4
17
mai
2010
# gourage de site
Posté par Albert_ . Évalué à -10.
[^] # Re: gourage de site
Posté par geh . Évalué à 6.
[^] # Re: gourage de site
Posté par vladislav askiparek . Évalué à 7.
«Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes pour être validées en dépêche, qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre avis. »
C'est là: http://linuxfr.org//journal/ en haut, à gauche.
[^] # Re: gourage de site
Posté par Albert_ . Évalué à -10.
Juste pour rigoler faisons un sondage de combien de personne utilise DARCs sur ce site et sur ces personnes combien le font sous windows. Je suis presque sur que en dehors du posteur cela tend vers 0...
[^] # Re: gourage de site
Posté par Frédéric Perrin (site web personnel) . Évalué à 8.
Quant à la pertinence de ce journal, moi je trouve que la recherche de testeurs pour un LL a sa place ici.
[^] # Re: gourage de site
Posté par Zenitram (site web personnel) . Évalué à 2.
Mais des utilisateurs de Windows et de Mac OS, il y en a plein.
Ce n'est pas parce qu'un logiciel libre ne correspond par à nos besoins (en l'occurrence Linux) que les milliers d'autres ne le sont pas non plus.
Et si on limitait les news à Linux seulement puisque tu souhaites qu'on parle que de Linux (Gnome, KDE, Firefox, SVN, GIT... ne sont pas du Linux, pas plus que DARCS en tous cas, avec ton argument on n'aurait pas le droit d'en parler non plus), il y aurait une seule dépêche tous les 6 mois, ce serait triste ton idée de site.
Non, il ne s'est pas gouré de site, il y a bien pas mal de gens qui utilisent CVS, SVN ou GIT sous Windows ici... Alors pourquoi pas DARCS.
[^] # Re: gourage de site
Posté par patrick_g (site web personnel) . Évalué à 9.
Hé ! C'est tous les 3 mois les news noyau !
[^] # Re: gourage de site
Posté par Dinofly (site web personnel) . Évalué à 3.
[^] # Re: gourage de site
Posté par CrEv (site web personnel) . Évalué à 3.
[^] # Re: gourage de site
Posté par pasBill pasGates . Évalué à 6.
On ne dit pas Linux, mais Ubuntu/Linux
[^] # Re: gourage de site
Posté par El Titi . Évalué à 3.
[^] # Re: gourage de site
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Je propose aussi qu'on interdise toutes les dépêches et tous les journaux qui traitent de nouveaux logiciels. Après tout, seuls leurs développeurs les utilisent, ça doit bien prouver qu'ils sont inutiles, sinon ils auraient plus d'utilisateurs.
Et je propose aussi que le logiciel libre ne tourne désormais plus qu'avec Ubuntu. Les autres distributions et OS sont trop marginaux pour qu'on se fasse chier à faire du code libre qui devrait être portable pour des gens dont on a rien à faire.
[^] # Re: gourage de site
Posté par Dr BG (site web personnel) . Évalué à 10.
[^] # Re: gourage de site
Posté par deleted_user . Évalué à 1.
Dracs est un logiciel non? Il est libre non? Le client windows est libre non?
Donc le post parlant d'un logiciel libre sur un site causant de logiciel libre est tout à fait à sa place.
D'ailleurs, juste pour le plaisir, j'ai lancé une VM windows XP rien que pour répondre sous windows tiens :)
# Lapin compris
Posté par El Titi . Évalué à 2.
Darcs réorganise automatiquement le graphe des commits en fonction des diffs, c'est ça ?
Quel est l'intérêt ?
[^] # Re: Lapin compris
Posté par geh . Évalué à 4.
Pour git/mercurial/bazaar, c'est pareil mais la différence est que le graphe est un graphe acyclique, càd qu'une révision peut avoir deux "révisions précédentes". C'est ce qui arrive quand on fusionne deux branches. Dans ce cas il y a un deuxième type de sommet qu'on pourrait appeler "point de fusion". Donc au moins on peut dire que git/mercurial/bazaar ont "conscience" de l'existence des branches, pas comme subversion.
Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.
Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.
Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.
Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de besoin de faire un patch qui résout les conflits, tu ne vois pas de trace de ta fusion.
De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes. Git s'en sortait mieux, il a une notion de "fast-forward" qui crée automatiquement ce point de fusion quand tout va bien, ça qui évite de devoir toujours faire comme avec mercurial et bazaar.
Résumé : darcs est plus simple à utiliser car il implémente la notion intuitive de "ce changement-ci dépend de ce changement-là".
[^] # Re: Lapin compris
Posté par El Titi . Évalué à 2.
Si tu prends subversion, le graphe qui est considéré c'est un graphe où les sommets sont des révisions et les arcs veulent dire "est la révision suivante de", et le graphe ne peut former qu'une ligne.
C"est encore plus simpliste que ça. Il s'agit d'une bête séquence linéaire de révision complète. Les branches et tag son simplement des recopies de sous-arborescence. Il n'y a pas de graphes (DAG) à proprement parler.
Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais
que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.
Oui c'est l'histoire des piquets et des barrières mais je ne vois pas ce que ca change.
Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit. Si tu as A->B et A->C et que tu veux réconcilier les modifs concurrentes de C avec B, tu dois, soit créer une revision C qui gère tes conflits, soit appliquer le patch C dans ton workspace et commiter un patch D après résolution. Avec git&Co, on a A->B, A->C, B->D et C->D
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
Pourtant c'est utile de conserver ce lien C->D pour éviter de réappliquer ce patch lors d'un futur merge éventuel entre ces 2 branches. C'est ce qu'on appelle la mémoire de merge.
Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.
Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).
Ensuite après ton pull, tu te retrouves quand même avec plusieurs heads (la tienne et la sienne) et il faut bien faire un resolve pour arbitrer les conflits.
Mercurial/Monotone fonctionnent comme ça de base aussi. quand à Git mis à part qu'une branche ne peut avoir qu'une head et qu'il faut les nommer ou qu'elles suivent des conventions (remote) il n'y a rien de plus à faire. Un conflit est un conflit et il faut le résoudre, non ?
Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
Chaque approche a ses avantages et ses inconvénients, on en a déjà un peu parlé ici.
http://linuxfr.org//comments/1125043,1.html
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes.
En gros le fait que le pull du repository et l'update de ton répertoire local soient 2 opérations différentes te gène.
Ca ne ma parait être un critère de décision primordial.
Aux dernières nouvelles, les perfs de darcs étaient bien en deçà de ses concurrents. Ca a changé depuis ?
[^] # Re: Lapin compris
Posté par geh . Évalué à 2.
Pour darcs, c'est essentiel de comprendre que gérer des patchs au lieu de gérer des révisions ça change quelque chose et c'est pas juste une représentation interchangeable avec une représentation orientée révisions.
Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.
(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit.
Quand il y a conflit, il faut créer un nouveau patch de résolution de conflit. Ce que je dis c'est que quand il n'y a pas de conflit (donc quand tout commute) alors il n'y a pas besoin de créer de patch supplémentaire.
Mais sinon l'exemple que tu présente est bon (à part que t'as inversé les flèches par rapport à moi). Sauf:
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
non, on aura pareil que dans ton cas de git: il faut créer un patch D qui dépend de B et de C (càd, qui modifie la même zone sur laquelle B et C sont en conflits).
Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).
Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.
Je peux imaginer que les power users de git habitués au checkout ne s'y retrouvent pas, en tout cas y'a de la demande pour des branches locales:
http://bugs.darcs.net/issue555
http://lists.osuosl.org/pipermail/darcs-users/2009-July/0205(...)
[^] # Re: Lapin compris
Posté par El Titi . Évalué à 2.
Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.
(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)
Oui mais même lorsqu'il n'y a pas de conflit, un système qui s'appuie sur des révisions gère/peut gérer aussi efficacement les changeset que les systèmes basés sur les patchs ala darcs ou Arch.
Avec la surcouche UCM de Clearcase par exemple tu as un système équivalent au merge: le deliver. tu peux choisir de reporter sélectivement un ou plusieur changeset et il y a une détection automatique si 1 changeset dépend de l'application d'un autre. Ca n'a rien à voir. A partir du moment moment où 2 révisions successives sont rattachées logiquement à un changement, c'est complètement équivalent à rattacher un diff à ce même.
Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.
Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.
OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.
Tu n'es pas obligé de les connaitre les 2 ni de les utiliser: le projet Mercurial en lui-même a choisi la même approche que toi pour son propre hébergement. Mais comme déjà indiqué chaque technique a ses propres avantages et inconvénients.
Je trouve rassurant de pouvoir changer d'approches lorsqu'on en a besoin.
Réfère toi à ce blog si tu veux plus d'infos pour comprendre les différences entre chaque approche.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)
Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.
cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.
[^] # Re: Lapin compris
Posté par geh . Évalué à 1.
D'accord, un tel système peut te générer le diff qui va bien quand tu lui demande de cherry-picker tel changement dans telle branche, mais ce diff n'est pas un objet de base manipulé par le système de gestion de versions, donc pas réutilisable et échangeable aussi librement qu'avec darcs.
>Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.
Oui il faut tout recalculer tant qu'on n'a pas une sorte de système de cache. Or un dépôt darcs contient le "pristine tree" qui est la somme des patchs du dépôt: http://upload.wikimedia.org/wikipedia/commons/6/69/Darcs-rep(...)
Merci pour ton lien Mercurial, je me ferai bientôt un ptit projet sur google code pour comprendre son approche.
>cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.
Ouep, pour les perfs ça pose problème, ceci dit quand les clones de dépôts sont faits sur le même système de fichiers, les liens durs sont utilisés le plus possible.
Pour l'intégration dans les IDE, bof je vois pas en quoi un système de répertoires frères poserait problème.
[^] # Re: Lapin compris
Posté par geh . Évalué à 2.
Oui, je pense que darcs reste aujourd'hui plus lent que ses concurrents, mais que la différence devient sensible seulement pour les gros projets. Actuellement le projet darcs a deux étudiants "summer of code" qui travaillent sur la performance (l'un sur les transferts réseau et l'autre sur l'amélioration du cache), en plus des développeurs permanents qui s'occupent aussi de ce problème. La version 2.5 (juillet) m'a l'air bien partie, par exemple ce bug est résolu dans la branche de développement : http://bugs.darcs.net/issue1106
Sans vouloir évacuer le problème, j'ai quand même envie de dire que si je dois taper 4 commandes dans git au lieu de taper 1 commande dans darcs pour faire la même chose, darcs a beau être plus lent pour une même opération atomique, il est plus rapide pour moi. Je dirais qu'il ne faut pas éliminer darcs a priori pour ça, tout comme on n'élimine pas Python parce qu'il est plus lent que C.
[^] # Re: Lapin compris
Posté par El Titi . Évalué à 1.
Le seul moyen de ne pas reconstruire une arbo à partir du premier patch est de stocker des révisions rattachées à des patchs particuliers.
Autant s'appuyer directement sur un système basé sur les révisions qui peut appliquer des optimisations (Delta inversé, ...)
Ensuite l'approche par clonage pose des problèmes puisque le fait de cloner n fois un repository distant ou des repositories clonés (cf. mon lien plus haut) surcharge le réseau pour rien. Il y a des possibilité d'optimiser avec un cache de chaque coté comme tu l'évoques mais ca ne règle pas le premier pb.
Après c'est sûr que si tu éludes la question des perfs, c'est plus facile.
[^] # Re: Lapin compris
Posté par geh . Évalué à 1.
> Autant s'appuyer directement sur un système basé sur les révisions qui peut appliquer des optimisations (Delta inversé, ...)
Avec quelques astuces (le pristine tree, le cache) on peut réduire les désagréments et obtenir des performances pas honteuses.
>Ensuite l'approche par clonage pose des problèmes puisque le fait de cloner n fois un repository distant ou des repositories clonés (cf. mon lien plus haut) surcharge le réseau pour rien. Il y a des possibilité d'optimiser avec un cache de chaque coté comme tu l'évoques mais ca ne règle pas le premier pb.
Depuis la version 2.2, il y a un cache de patchs pour chaque utilisateur, donc faire un deuxième clone d'un dépot distant est rapide, et faire des clones locaux également.
>Après c'est sûr que si tu éludes la question des perfs, c'est plus facile.
Je regrette de donner cette impression mais j'essaye d'expliquer pourquoi je trouve cet outil valable. En 3 ans d'utilisation je ne me suis jamais plaint des perfs, donc elles ne sont pas si horribles. Le problème c'est que comme les gens (peu nombreux) qui codent des projets "stars" de l'ampleur de Firefox ou du noyau linux sont très audibles dans la communauté du logiciel libre, tout le monde a tendance à prendre leurs préoccupations pour les siennes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.