Articles précédents : Développeur
- [188] En quoi la mise en page par tableaux est-elle stupide
- [15] Les documentations de l'OpenGroup bientôt dans votre pingouin
- [78] GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
- [22] UML2PHP5 version 0.3
- [2] Résumé GNOME 13-12-2003
- [11] "Débats virtuels" autour des *BSD
- [13] Les coulisses du développement de Python
- [20] Résumé GNOME 06-112-2003
- [32] Anjuta 1.2
- [10] Le nouvel OpenZaurus est arrivé !
Liens connexes
- The New Breed of Version Control Systems (3916 hits)
- Better SCM Initiative : Comparison (1601 hits)
Dépêche modérée par
Développeur : Comparatif des systèmes de contrôle de version
Posté par Foxy (page perso, ). Modéré le 10 février 2004.
L'auteur revient rapidement sur l'utilité d'un système de contrôle de version (CVS étant le plus utilisé à l'heure actuelle) lorsqu'un projet atteint une taille importante et que le développement se fait à plusieurs.
Puis il liste les fonctionnalités communes à ces systèmes : commits atomiques, merge de branches, "repositories" distribués, renommage/suppression de répertoire/fichier avec conservation de l'historique du versioning... (désolé pour ce franglais mais les utilisateurs de ces systèmes me comprendront ;-) ).
ll présente enfin les avantages et inconvénients des systèmes suivants : CVS, Subversion, Arch, OpenCM, Aegis, Monotone et BitKeeper.
Une lecture conseillée à toute personne souhaitant travailler sur un projet à plusieurs développeurs et se faire une idée de ce qui existe pour cela en dehors de CVS.
Note du modérateur : j'ai rajouté le second lien évoqué dans une dépêche précédente.
![[en]](../../../images/en.png)
The New Breed of Version Control Systems (3916 hits)-
Better SCM Initiative : Comparison (1601 hits)
> Lire la dépêche (59 commentaires, moyenne: 1,6).
Re: Comparatif des systèmes de contrôle de version
On vient de parler de Subversion il y a quelques jours. Voici un lien qui a fait surface lors de la discussion, et qui est nettement plus informatif que l'article d'OnLamp lui-même :
http://better-scm.berlios.de/comparison/(...)
Quelques corrections en ce qui concerne l'article :
* Arch commence à fonctionner sous Cygwin/Windows.
* Même si Arch en version 1.1 est normalement stable, la version 1.2 apportera le support de l'intégrité et de la signature des archives (en mettant des hash MD5/SHA1 et des signatures PGP un peu partout), ce qui obligera à convertir ses archives existantes. Bien que cela ne doive pas poser trop de problème, moi je préfère attendre 1.2 pour me mettre sérieusement à Arch.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Foxy (page perso, ) le 10/02/2004 à 08:25. (lien). Évalué à 2.Je suis en train de mettre sérieusement à Arch et effectivement la version 1.2 apporte des solutions au niveau de l'intégrité et de la signatures des archives (MD5 + signature du commit log via GPG).
C'est un grand plus qui a été initié suite au "hack" qui avait eu lieu il y a quelques semaines dans le repository du noyau Linux.
Au passage, je suis en train de créer le port de TLA (client shell pour Arch) pour OpenBSD pour la version 1.1. En espérant qu'il sera rapidement intégré à l'arbre des ports officiel.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par VACHOR (page perso, ) le 10/02/2004 à 09:14. (lien). Évalué à 2.Effectivement, un excellent travail réalisé à l'URL indiquée.
A noter l'existence d'un plugin subversion pour Eclipse, il s'appelle subclipse (http://subclipse.tigris.org/(...)). Je pense que je vais essayer ça dès que possible...-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Dreammm () le 10/02/2004 à 12:37. (lien). Évalué à 1.La derniere fois que j'ai regardee, il ne marchait que pour Windows :-(
Extrait de la FAQ :
"Why does Subclipse only support Windows?
A linux version is planned. "
Ca me freine beaucoup dans mon utilisation d'Eclipse+ subversion.-
[^]Re: Comparatif des systèmes de contrôle de version
-
-
Re: Comparatif des systèmes de contrôle de version
désolé pour ce franglais mais les utilisateurs de ces systèmes me comprendront
Ceux qui veulent apprendre ne comprennent pas forcément. Alors bien sûr il y a google sous le coude mais autant éviter un jargon qui peut être parfois rédhibitoire.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Silence (page perso, ) le 10/02/2004 à 08:07. (lien). Évalué à 4.Le plus simple aurait été de donner la version francaise... afin que ceux qui ne comprennent pas, le puissent :
conservation de l'historique du versioning = conservation de l'historique des versions
En plus c'était fastoche :^)--
^d^c-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Nÿco (Jabber id, page perso, ) le 10/02/2004 à 08:25. (lien). Évalué à 0.versioning ne se traduit pas par versions
--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: Comparatif des systèmes de contrôle de version
-
[^]Traduction
Posté par LupusMic (page perso, ) le 10/02/2004 à 09:29. (lien). Évalué à 1.Versonification ?
Attention ! C'est presque de la technique poêtique ;)-
[^]Re: Traduction
-
-
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par tinodeleste () le 10/02/2004 à 08:25. (lien). Évalué à 5.Ceux qui veulent apprendre ne comprennent pas forcément. Alors bien sûr il y a google sous le coude mais autant éviter un jargon qui peut être parfois rédhibitoire.
le mieux c'est de comprendre la base cvs:
http://www.freenix.org/curiosite/cvs.html(...)
ca permet de voir que commit (commettre ?), merge (fusionner ?) et repositories (dépôts ?) ne sont pas incompréhensibles parce qu'ils sont en anglais, mais parce que leur sens est lié à leur cadre d'utilisation...-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par cumulus () le 10/02/2004 à 08:43. (lien). Évalué à 2.commit (commettre ?), merge (fusionner ?) et repositories (dépôts ?) ne sont pas incompréhensibles parce qu'ils sont en anglais, mais parce que leur sens est lié à leur cadre d'utilisation...
Je n'en doute pas ! J'estime juste que dans le cadre d'une news, il serait bon d'être le plus explicite possible. Merci pour ton lien !
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par #3588 () le 10/02/2004 à 09:20. (lien). Évalué à 2.Dépôt et fusionner oui, commettre c'est quand même pas terrible... Dans ton lien ils proposent enregistrer, c'est mieux mais ça peut porter à confusion... Appliquer me paraît mieux. Quelqu'un voit d'autres candidats ?
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Quzqo () le 10/02/2004 à 15:57. (lien). Évalué à 1.reporter en configuration ? versionner (bof) ?
Dans un SCM (comprendre Système de Gestion de Configuration), il y a pour moi x étapes :
° Pour un objet versionné (VO) : fichier ou répertoire
- Créer/Référencer en gestion de configuration un VO : create ou mkelem
- Editer un VO (pour le modifier <=> définir son contenu lors de la création) : checkout
- Reporter en configuration une modification d'un VO : commit ou checkin
- Détruire un VO : remove ou rm
- Déréférencer un VO (supprimer toutes les références d'un VO) : rmelem
° Pour les opérations de gestion de versions :
- Créer une branche de version : branch ou mkbranch
- Fusionner deux versions : merge
- Comparer ... : diff
- Créer une étiquette (tag ou label) : mklbtype
- Poser une étiquette : tag ou mklabel
Et je dois en oublier... ,o)
PS: quelques exemples de commandes fournis en italique (diffèrent selon les SCM ou ne sont pas toujours présents)--
BXN - La vie est un (men)songe.
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par bobert () le 10/02/2004 à 09:41. (lien). Évalué à 2.to commit (dans ce contexte) -> valider
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Mr F (page perso, ) le 10/02/2004 à 12:36. (lien). Évalué à 0.Certainnement pas.
To commit = Confier
ça me parait un peu plus correcte vu que l'action consiste à envoyer les données modifiés au serveur. On pourrait aussi le traduire par envoyer je pense. Il n'y a aucun processus de validation la dedans.-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par daverick () le 10/02/2004 à 13:39. (lien). Évalué à 0.Quand j'ai un problème de traduction, je vais voir http://w3.granddictionnaire.com(...)
>>
Le terme archiver désigne mieux cette opération complexe que les termes valider et soumettre, couramment employés, qui n'en recouvrent que partiellement le concept.
L'utilisation du terme commit en français, comme dans faire un commit ou dans la forme verbale francisée commiter, est répandue dans Internet dans des sources d'origine française. Il s'agit d'un emprunt inutile à l'anglais to commit. Au Québec, cet anglicisme ne semble pas en usage.
[Office québécois de la langue française, 2002]
<<-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Mr F (page perso, ) le 10/02/2004 à 17:25. (lien). Évalué à 1.Non, je ne suis pas d'accord, En l'occurence tu n'archive pas sur le cvs, ce n'est pas une archive du tout !!! C'est un endroit de travail ou le/les fichier(s) seront accessible de tous.
Une traduction ce n'est jamais du mot à mot, il faut prendre le contexte et dans celui ci, "confier" correspond bien mieux.
Et moi personnellement, quand j'ai un problème de traduction je prend mon "Larousse Français/Anglais".
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par bobert () le 10/02/2004 à 17:30. (lien). Évalué à 0.Certainnement pas.
Ah bon, vraiment ? Des références pour appuyer cette affirmation ?
De mon côté, voici de quoi appuyer mon sentiment que l'expression to commit a transaction, puisque c'est de cela qu'on parle, soit couramment traduite en Français par valider une transaction:
- Cours Supelec:
http://wwwlsi.supelec.fr/www/yb/poly_bd/sql/poly_47.html(...)
- Office québécois de la langue française:
http://www.olf.gouv.qc.ca/ressources/bibliotheque/dictionnaires/Int(...)
- Cours du CNAM:
http://datom.dyndns.org/Cnam/cours(...) 2003 - 2004/Client Serveur/MT.pdf
- Cours du LORIA:
http://www.loria.fr/~skaf/cours/sybase/transaction/tsld055.htm(...)
Dois-je continuer ?
To commit = Confier
ça me parait un peu plus correcte vu que l'action consiste à envoyer les données modifiés au serveur. On pourrait aussi le traduire par envoyer je pense. Il n'y a aucun processus de validation la dedans.
Je me permets de te renvoyer aux liens suscités pour apprendre les notions de transaction et d'atomicité, que visiblement tu ne maîtrises pas.
La validation d'une transaction survient après avoir modifié des données au sein de cette transaction. Ainsi avec cvs, on n'effectue de cvs commit (validation de la transaction) qu'après un cvs {update, add, delete}
Je te propose également de te renseigner un minimum avant d'affirmer des conneries. Il s'agit de vocabulaire technique, et ouvrir ton dico Anglais-Français pour espérer trouver la bonne traduction est illusoire. Le plus judicieux étant tout simplement de faire confiance à qqn qui a plus d'expérience que toi dans un domaine donné. - Cours du CNAM:
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Rhaegar () le 10/02/2004 à 20:52. (lien). Évalué à 0.Faudrait peut-être aller chercher des définitions qui correspondent au contexte. Ce n'est pas en prenant la première définition venue sans se soucier du contexte que ce sera la bonne. C'est ce que fait un traducteur automatique, ou quelqu'un qui n'y connaît rien.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Mr F (page perso, ) le 11/02/2004 à 01:55. (lien). Évalué à 1.Effectivement, je me suis trompé (dans l'hypothése ou effectivement cvs effectus des tâches de vérification/validation/certification, je n'irais pas vérifier, je te fais confiance, cvs ne se contente pas d'inclure le fichier mais il effectue un processus de validation quelquonque, car sinon confier est plus approprié).
Pour ton expèrience, désolé, j'suis pas sensé savoir que l'on doit croire sur parole et sans justification aucune ce que tu dis (proclame ?).
Pour ton agressivité, admettons que ma phrase "Certainnement pas" t'es froissé. Admettons.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par #3588 () le 11/02/2004 à 10:07. (lien). Évalué à 1.« De mon côté, voici de quoi appuyer mon sentiment que l'expression to commit a transaction, puisque c'est de cela qu'on parle, soit couramment traduite en Français par valider une transaction: »
C'est une proposition connue, et qui n'est pas nettement meilleure que d'autres comme archiver, confier, appliquer. C'est un peu mieux que les traductions un peu trompeuses « mettre à jour » et « exporter » qui nécessitent de préciser que la cible est le dépôt, pas le répertoire de travail.
Le problème, c'est que malgré ce que tu dis, tu fais bien de la traduction littérale : tu prends la même notion dans un domaine différent (les SGBD) et tu la traduis dans ce domaine là sans réfléchir. C'est compréhensible pour un admin de bases de donner (comme « confirmer »), mais il faut aussi apprendre à traduire, ce que visiblement tu ne maîtrises pas (pour te reprendre cette expression sympathique). Valider a bien d'autres sens, et c'est ce qui fait que ce mot est assez peu utilisé dans ce contexte, le franglais et des expressions plus longues sont employés pour éviter les confusions. Ça peut être une traduction mais c'est une traduction médiocre, donc si on se pose le problème de la traduction on ne s'en satisfait pas.-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Xavier Jacquelin (Jabber id, page perso, ) le 22/02/2004 à 00:37. (lien). Évalué à 1.
C'est une proposition connue, et qui n'est pas nettement meilleure que d'autres comme archiver, confier, appliquer. C'est un peu mieux que les traductions un peu trompeuses « mettre à jour » et « exporter » qui nécessitent de préciser que la cible est le dépôt, pas le répertoire de travail.
Valider est le terme le plus utilisé, parce que justement c'est la même notion que pour les SGBD, en effet on valide les changements effectués. Et c'est meilleur que "archiver" (qui ne vuet rien dire dans ce contexte, puisqu'on archive rien), et surtout que "confier" (qui ne veut absolument rien dire ici, quand tu fais un delete puis un commit tu ne confis rien au serveur cvs). Pour "appliquer" ça pourrait passer en précisant appliquer les chagements car appliquer est un terme très générique.
Et je ne vois pas le rapport avec de la traduction littérale, c'est un terme technique, soit on a 1 terme officiel, soit on utilise le terme le plus usité, mais on ne met pas n'importe quoi parce que ça nous plaît, après pour se comprendre si chacun utilise le terme qui lui plaît on a pas fini (et c'est d'ailleurs pour ça, AHMA, que les gens gardent souvent le terme anglais ou sa francisation).
-
-
[^]Re: Comparatif des systèmes de contrôle de version
- Cours Supelec:
-
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par anonyme512 () le 11/02/2004 à 09:01. (lien). Évalué à 1.repositories (dépôts ?)
la traduction plus ou moins officielle pour repository est référentiel, ce qui "rend" très bien les caractéristiques de la chose, et notamment l'aspect "référence" que constitue cet élément du système de controle de versions (alors qu'un dépôt a l'inconvénient d'être dans son sens plus statique, moins "intelligent", notamment par rapport au mécanisme de mise à jour avec fusion effectué à partir de cet élément).
Pour commit, je proposerais du coup "envoyer", mais il est vrai que "valider" reste pas mal. Ceci dit, je ne suis pas sûr qu'il y ait tellement d'équivalents français pour le terme, et il serait peut etre sage à ce niveau de faire un enrichissement de la langue française, ce qui permettrait de discuter plus avant sur les bienfaits du commit de situation ou de répétition.
-
Re: Comparatif des systèmes de contrôle de version
Boaf, franchement, elle est pas terrible cette comparaison. Je trouve que celle-ci est bien plus exhaustive :
http://better-scm.berlios.de/comparison/(...)
(tous ces liens ont déjà été cités dans la news sur subversion RC1 http://linuxfr.org/2004/02/04/15330.html(...) )
_pini.
P.S. : tient, salut Fox, ça va ?
L'entreprise est la moins démocratique des organisations humaines.
-
[^]Re: Comparatif des systèmes de contrôle de version
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Foxy (page perso, ) le 10/02/2004 à 08:29. (lien). Évalué à 1.J'ai jamais dit que cette comparaison était la panacée. C'est juste un "must read" pour ceux qui veulent se mettre aux outils de versioning et penser à utiliser autre chose que CVS qui commence à être largement dépassé (Attention, troll detected)
PS : oui ça va très bien Pini, faudrait qu'on se voit vu qu'on habite à 50m l'un de l'autre ;-)-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par #3588 () le 10/02/2004 à 09:27. (lien). Évalué à 3.« CVS qui commence à être largement dépassé (Attention, troll detected) »
Ce n'est pas un troll, je pense que quasiment tout le monde est d'accord là dessus. Le problème c'est d'avoir des alternatives fiables (on doit y être tout juste) et répandues (sur les sourceforge-like notamment).
C'est comme les autoconf/automake etc. Ça reste les meilleures solutions pour différentes raisons mais par bien des côtés ils sont « dépassés ». Dans leur cas il y a des alternatives mieux conçues mais qui ont d'autres inconvénients (par exemple des dépendances vers autre chose que make pour l'utilisateur final).-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Alan_T () le 10/02/2004 à 11:48. (lien). Évalué à 1.Tu as tout à fait raison pour CVS !!!
Mais, puisque tu parles de autoconf/automake, est-ce que quelqu'un connait des alternatives ???-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par David pasmalin (page perso, ) le 10/02/2004 à 12:25. (lien). Évalué à 2.Comme alternative a autoconf automake je te propose pmk :)
http://pmk.sourceforge.net/(...) <= la
voila voila
pm-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par William Steve Applegate (page perso, ) le 10/02/2004 à 15:16. (lien). Évalué à 1.Je crois me rappeler l'avoir essayé (mais ça ne m'a à l'évidence pas trop marqué), et il me semblait avoir compris que le principe était d'utiliser ce fameux programme 'pmk' pour interpréter le Makefile.in. Ça ne me plaît pas trop à vrai dire, car cela entraîne du coup une dépendance sur ce programme pour compiler le soft, tandis qu'un soft utilisant automake/autoconf n'a besoin que d'un shell (qui n'a pas beaucoup de chances d'être absent :-) Je vois bien des soluces, comme livrer un binaire statique dudit pmk avec le soft, mais c'est bancal : quid des gens utilisant une autre archi que la mienne ? Au moins, la soluce autoconf a l'avantage d'être universelle (même si c'est vraiment horrible d'obtenir un Configure.in indéboguable à souhait)...
--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par William Steve Applegate (page perso, ) le 10/02/2004 à 15:43. (lien). Évalué à 1.Et, tant qu'on en est à parler des alternatives à autoconf, quelqu'un a-t-il essayé package-framework [http://freshmeat.net/projects/package-framework/(...)] ? C'est fait par le même auteur qu'Arch (je viens d'ailleurs de le découvrir à cause de ça :-) mais j'en sais pas beaucoup plus, il ne semble même pas avoir de page Web... Quelqu'un connaît ?
--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par megablorb () le 12/02/2004 à 13:34. (lien). Évalué à 1.Je crois me rappeler l'avoir essayé (mais ça ne m'a à l'évidence pas trop marqué), et il me semblait avoir compris que le principe était d'utiliser ce fameux programme 'pmk' pour interpréter le Makefile.in.
Effectivement.
Ça ne me plaît pas trop à vrai dire, car cela entraîne du coup une dépendance sur ce programme pour compiler le soft, tandis qu'un soft utilisant automake/autoconf n'a besoin que d'un shell (qui n'a pas beaucoup de chances d'être absent :-)
Ca c'est en theorie, dans la pratique on a souvent besoin d'avoir autoconf sur le systeme. Il suffit de prendre un arbre des ports de n'importe quel BSD pour se rendre compte qu'il y a une dependance avec l'un des deux dans pas mal de ports. A choisir entre autoconf et pmk d'installe je prefere pmk car il est plus rapide et prends moins de place.
D'un autre cote grace a pmk on se debarrasse du gros script shell qu'est "configure" (j'en ai deja vu qui depassaient les 10 mille lignes !!) qui peut etre une source d'ennui si quelqu'un de malicieux veut y introduire un troyan. Chose qui est deja arrivee plusieurs fois ...
Et puis cote dependances il n'y a besoin que de pmk sachant que celui-ci ne necessite qu'un compilateur C et un shell. C'est donc loin d'etre si chiant que ca. En plus rien n'empeche de fournir un package contenant les deux solutions sachant qu'elles reposent toutes les deux sur le meme concepte de remplacement de tags.
Je vois bien des soluces, comme livrer un binaire statique dudit pmk avec le soft, mais c'est bancal : quid des gens utilisant une autre archi que la mienne ?
Ca n'est pas le but il me semble.
Au moins, la soluce autoconf a l'avantage d'être universelle (même si c'est vraiment horrible d'obtenir un Configure.in indéboguable à souhait)...
Effectivement, elle est universellement connue pour etre une source d'emmerdes. Plus serieusement je suis d'accord que l'idee de base d'avoir un script de configuration portable est sympa. Mais dans la pratique le dit script peut s'averer dangereux et comme dit plus haut on s'apercoit que finalement autoconf a souvent besoin d'etre installe sur le systeme.
-
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par #3588 () le 10/02/2004 à 12:30. (lien). Évalué à 0.Personnellement j'ai eu affaire à Ant, qui semble très bien (ceux qui l'utilisent en tant que développeurs sont en général enthousiastes) mais qui doit être présent sur la machine où se fait l'installation. Et comme il nécessite Java, j'avais trouvé ça très pénible (évidemment c'est moins genant pour ceux qui ont déjà Java).
-
-
-
Pour plus d'info sur la gestion de configuration/version et le libre
Au cour de mon DESS Qualité et sûreté de fonctionnement des systèmes informatiques, j'ai eu l'occasion de réaliser un mini-projet dont le sujet était «Gestion de configuration avec CVS».
J'ai réutilsé les slides lors de la présentation que j'ai faite à Solution Linux 2004.
Je suis preneur de tous commentaires/correctifs, et même d'une traduction en anglais.
http://www.librapport.com/document.php?iddocument=45(...)
-
[^]Re: Pour plus d'info sur la gestion de configuration/version et le libre
Posté par thomas () le 10/02/2004 à 09:16. (lien). Évalué à 3.CVS est un outil de gestion de versions de fichiers, pas un outil de gestion de configuration ....
-
[^]Re: Pour plus d'info sur la gestion de configuration/version et le libre
Posté par Nÿco (Jabber id, page perso, ) le 10/02/2004 à 09:27. (lien). Évalué à 1.Peux-tu me définir l'experssion "Gestion de Configuration" ? Ce que c'est censé faire / ne pas faire ? (j'ai l'impression que c'est plutôt une expression marketing pour que les vendeurs de bouses proprios et opaques puissent se gargariser et inonder les 01papier...)
Gforge et Savane sont-ils des outils de gestion de conf ? ...bien plus ?
http://gforge.org/(...)
https://gna.org/projects/savane(...)
Pour info, ça intègre un CVS, un bugzilla, parfois peut-êtres des outils de compilations journalières automatiques, mais aussi des outils de gestion de documents, des gestionnaires de tâches, outils de gestion de projet, agendas, mailing-lists et parfois aussi des serveurs Jabber, bref une palette complète (ou presque) et intégrée d'outils collaboratifs (groupware).--
Jabber ID : xmpp:Nyco@jabber.fr
-
[^]Re: Pour plus d'info sur la gestion de configuration/version et le libre
-
Re: Comparatif des systèmes de contrôle de version
Bon en gros : Arch ou Subversion ?
J'ai l'impression que selon les besoins la réponse ne va pas être la même. Quels sont les points forts de l'un et de l'autre ?
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Foxy (page perso, ) le 10/02/2004 à 09:26. (lien). Évalué à 1.Un repository Arch est super facile à publier : il utilise HTTP, FTP, SFTP ou Webdav comme sous-jacent pour le stockage. Il suffit d'avoir un serveur configuré pour un de ces protocoles pour pouvoir héberger un dépôt Arch.
Pour Subversion, c'est un peu plus compliqué car il faut configurer un serveur Apache2 (obligatoirement version 2) + module Webdav.
Sinon, pour points forts/faibles, voir comparatif déjà cité plus haut dans les commentaires.-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Matthieu Moy (page perso, ) le 10/02/2004 à 10:20. (lien). Évalué à 3.En fait, la vraie question est :
Lequel est susceptible de remplacer cvs en temps que truc super standard, installé sur plein de machines, proposé par pleins d'hébergeurs, ...-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Nÿco (Jabber id, page perso, ) le 10/02/2004 à 10:46. (lien). Évalué à 1.Subversion : il a été développé pour ça.
--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par free2.org (page perso, ) le 10/02/2004 à 15:25. (lien). Évalué à 2.d'après l'article arch peut fonctionner chez savannah et sourceforge
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par jmfayard () le 10/02/2004 à 11:22. (lien). Évalué à 1.Sur ce point :
cvs n´est pas pres de disparaitre de sitot, donc une autre vraie question est de savoir si le systeme de controle de version pour inter-operer avec ce truc super standard installe sur plein de machines.
Ca se fait assez facilement avec arch :
http://wiki.gnuarch.org/moin.cgi/Interoperating_20with_20CVS(...)
Un gourou de subversion pour nous dire si/comment c´est possible avec subversion ?
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Christophe Fergeau () le 10/02/2004 à 12:08. (lien). Évalué à 1.Pour arch, tu n'as pas besoin de serveur, il te suffit d'avoir un accés sftp/http/ftp sur un serveur pour pouvoir publier l'historique intégral de ton module. Par contre il faut ensuite que le client qui va bien soit installé sur les machines clientes dans une version suffisamment à jour, et ça c'est un autre problème ;) (les fonctionnalités et la syntaxe en ligne de commande de tla ont tendance à bouger assez rapidement).
-
-
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par jmfayard () le 10/02/2004 à 11:15. (lien). Évalué à 3.Une reponse (deja citee la derniere fois) en provenance d´une source objective :
http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison(...)
On y trouve une opinion interessante que je ne suis pas loin de partager :
Opinion: I think the main reason why you would want to use Subversion is that it is an easy step from CVS. The development model (central repo, no locking, etc) is similar, and a developer experienced on CVS can be using Svn for basic operations in a matter of minutes. Subversion fixes a number of annoyances in CVS, including lack of renames and whole-tree commits, and is more pleasant to use than CVS. Svn is much less amibitious in scope than Arch, and missing major architectural features such as distributed branching. Subversion (as of 2003) is much better documented than Arch, which also makes the switch earlier.
So: Subversion is an easier step from CVS. But if you're going to switch, maybe you should just go all the way to Arch.
Plus generalement, si vous vous interessez a arch, ce wiki est excellent et de loin la meilleure documentation pour l´instant.
http://wiki.gnuarch.org/moin.cgi/FrontPage(...)
Re: Comparatif des systèmes de contrôle de version
Il existe aussi DARCS que j'ai découvert récement, et qui semble très intéressant avec ses patchs sémantiques.
http://abridgegame.org/darcs/(...)
Si quelqu'un connait et a un avis sur la question, je suis curieux.
Re: Comparatif des systèmes de contrôle de version
Pourquoi BitKeeper a t il choisi pour faire a gestion de source de linux?
C est l un des seul du comparatif a ne pas etre avec une license open source alors qu il semble y avoir des projets aux fonctionnalités équivalentes avec une license qui serait plus dans l esprit de l open source?
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Christophe Fergeau () le 10/02/2004 à 12:22. (lien). Évalué à 2.Parce que quand linus a commencé à utiliser bitkeeper, c'était le seul qui correspondait à ses critères (qui sont principalement la possibilité de developpement distribué, et un système de gestion de fusion de différentes branches en provenance de divers endroits très puissant). Aujourd'hui, je pense que arch pourrait convenir pour cela, mais n'ayant pas testé bitkeeper, il est possible que celui-ci soit plus performant/plus rapide que arch pour ce genre de scénario. De toute façon, à l'époque où linus a fait son choix, bitkeeper était probablement le seul outil viable pour faire ce qu'il voulait. Et même aujourd'hui, arch n'est pas assez mature pour un projet de la taille du noyau à mon avis.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par #3588 () le 10/02/2004 à 12:39. (lien). Évalué à 3.L'auteur de BitKeeper travaillait sur Linux avant (et maintenant encore sans doute), il connaissait bien Linux et les problèmes de gestion de version spécifiques au développement du noyau. BitKeeper a été quasiment fait pour Linux (évidemment il convient pour d'autres projets) et c'est normal qu'il se soit retrouvé comme "meilleur" outil pour Linux (indépendamment de l'aspect libre). L'auteur a misé sur la réputation qu'il obtiendrait en étant retenu, il y a consacré du temps, et pour rentabiliser ce n'est pas libre. Mais si le critère libre avait été imposé dès le départ (si Linus avait dit que toute gestion de version devait se faire avec du libre) ce logiciel n'aurait a priori pas été créé.
-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par Philippe Fremy (page perso, ) le 10/02/2004 à 16:57. (lien). Évalué à 1.> L'auteur a misé sur la réputation qu'il obtiendrait en étant retenu
Il a peut-etre aussi eu envie de pousser les developpeurs du noyau a utiliser autre chose que mutt + patch pour gerer le projet open source le plus populaire de la planete ? Je te trouve un peu reducteur dans le motivations de l'auteur.
> Mais si le critère libre avait été imposé dès le départ ce logiciel n'aurait a priori pas été créé.
pure extrapolation de ta part. Il y a deux ans, bitkeeper etait developpe et vendu alors que Linus ne l'utilisait pas. Bitkeeper aurait semble-t-il continue sa vie avec ou sans Linus. Le fait que Linus l'utilise lui a fait de la pub mais c'est tout.
Pour ma part, je pense qu'il a cherche le meilleur compromis qu'il a pu entre liberte et rentabilite. Beaucoup critiquent, mais combien de ceux qui critiquent arrivent a vivre de logiciel libre (ou pseudo-libre).
La licence est un peu bizarre mais en gros, si tu ne developpe pas un concurrent de bitkeeper et si tu publies tes sources, tu n'as pas de problemes pour l'utiliser ou le modifier.
Je sais pas si tout le monde realise que Linus avait place la barre tes haut pour un outil de gestion de conf pour le noyau. Si le truc ne faisait pas minimum du reporting branche en branche (ou depot a depot) avec approbation des changements, c'etait meme pas la peine de lui proposer.-
[^]Re: Comparatif des systèmes de contrôle de version
Posté par #3588 () le 11/02/2004 à 10:21. (lien). Évalué à 2.« Il a peut-etre aussi eu envie de pousser les developpeurs du noyau a utiliser autre chose que mutt + patch pour gerer le projet open source le plus populaire de la planete ? Je te trouve un peu reducteur dans le motivations de l'auteur. »
Tu as coupé ma phrase, je ne parlais pas de la motivation pour réaliser le logiciel mais de ce qui a motivé le choix de la licence. S'il ne s'était soucié que du noyau et de ses développeurs, BitKeeper serait libre afin d'avoir l'adhésion de tous les développeurs. Certains développeurs du noyau ne seraient pas non plus interdits d'utilisation de la version gratuite de BitKeeper.
« pure extrapolation de ta part. Il y a deux ans, bitkeeper etait developpe et vendu alors que Linus ne l'utilisait pas. Bitkeeper aurait semble-t-il continue sa vie avec ou sans Linus. Le fait que Linus l'utilise lui a fait de la pub mais c'est tout. »
Il était évident que je parlais de BitKeepr tel qu'il existe aujourd'hui (ce qu'il était avant, ce n'est pas la question). Tu soutiens donc que la participation de son auteur à la LKML et l'utilisation de BitKeeper pour le noyau n'a strictement aucun effet sur son évolution, ses fonctionnalités, les outils associés, etc. ?
« Pour ma part, je pense qu'il a cherche le meilleur compromis qu'il a pu entre liberte et rentabilite. Beaucoup critiquent, mais combien de ceux qui critiquent arrivent a vivre de logiciel libre (ou pseudo-libre). »
C'est quelque chose que je n'ai pas critiqué dans mon post. Mais si tu comptes entamer cette question, il va de soi que l'argument selon lequel « les autres » ne font pas de rentabilité avec du libre ne vaut rien. Il fait le choix de sa licence. Le logiciel est propriétaire, ce n'est pas parce que l'auteur a fait ce choix pour telle ou telle raison que ça supprime les inconvénients habituels du logiciel propriétaire. La démarche est propriétaire, je ne suis pas sûr qu'il y ait grand chose à dire de plus...
« La licence est un peu bizarre mais en gros, si tu ne developpe pas un concurrent de bitkeeper et si tu publies tes sources, tu n'as pas de problemes pour l'utiliser ou le modifier. »
La première chose que l'on voit c'est que la liberté zéro n'est pas respectée. Même s'il y a de petits bouts des libertés suivantes, elles sont bien bancales. Pourquoi chercher à atténuer qu'un logiciel propriétaire est propriétaire ? Il peut avoir ses qualités mais il reste propriétaire, ça ne préjuge pas de sa fiabilité, de ses capacités et de choses comme ça...
« Je sais pas si tout le monde realise que Linus avait place la barre tes haut pour un outil de gestion de conf pour le noyau. Si le truc ne faisait pas minimum du reporting branche en branche (ou depot a depot) avec approbation des changements, c'etait meme pas la peine de lui proposer. »
Bien sûr Linus ne l'a pas choisi sans bonnes raisons. Mais est-ce que quelqu'un a contesté ce fait ?
-
-
Format de stockage
J'aimerais poser une question à ceux qui ont utilisé Arch et/ou Subversion, sous quel format sont stockées les données ?
RCS (non, c'est démodé ...) , DataBase, xml, autre chose ?
Merci pour vos réponses/liens éventuels
-
[^]Re: Format de stockage
Posté par Christophe Fergeau () le 10/02/2004 à 13:31. (lien). Évalué à 1.Pour arch, je pense que c'est un mix de fichiers textes et de diff (tout ça plus ou moins gzippé). Libre à toi de fouiller sur http://cfergeau.free.fr/arch/(...) pour étudier comment arch stocke ses données ;)
-
[^]Re: Format de stockage
Posté par Éric (Jabber id, page perso, ) le 10/02/2004 à 13:37. (lien). Évalué à 1.Pour subversion ce sont des fichiers berkleyDB, donc pas lisibles directement contrairement à CVS (ou Arch aussi je crois)
Re: Comparatif des systèmes de contrôle de version
Pour ceux que ca interesse il y a actuellement un thread sur FreeBSD-hacker pour la migration de CVS vers subversion :
http://lists.freebsd.org/pipermail/freebsd-hackers/2004-February/00(...)
migrer un tel projet qui a 10 ans de CVS derriere lui n'est pas une chose qui s'improvise c'est d'ailleur juste une reflexion pour le moment.
Autrement il y a perforce qui est utilisé pour certaines branches (trustedbsd par exemple).
Cette page a été générée par Templeet en 0.1973s (dont 0.0232 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.