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.
Aller plus loin
- The New Breed of Version Control Systems (245 clics)
- Better SCM Initiative : Comparison (155 clics)
# Re: Comparatif des systèmes de contrôle de version
Posté par Boa Treize (site web personnel) . Évalué à 9.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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
Posté par gabuzo . Évalué à 1.
# Re: Comparatif des systèmes de contrôle de version
Posté par cumulus . Évalué à 4.
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 Yohann (site web personnel) . Évalué à 4.
conservation de l'historique du versioning = conservation de l'historique des versions
En plus c'était fastoche :^)
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Nÿco (site web personnel) . Évalué à 0.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par #3588 . Évalué à 3.
[^] # Traduction
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Attention ! C'est presque de la technique poêtique ;)
[^] # Re: Traduction
Posté par jeff110 . Évalué à 1.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par tinodeleste . Évalué à 5.
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 . Évalué à 2.
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 . Évalué à 2.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Quzqo . Évalué à 1.
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)
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par bobert . Évalué à 2.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Mr F . Évalué à 0.
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 . Évalué à 0.
>>
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 . Évalué à 1.
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 Nÿco (site web personnel) . Évalué à 0.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par bobert . Évalué à 0.
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:
http://wwwlsi.supelec.fr/www/yb/poly_bd/sql/poly_47.html(...)
http://www.olf.gouv.qc.ca/ressources/bibliotheque/dictionnaires/Int(...)
http://datom.dyndns.org/Cnam/cours(...) 2003 - 2004/Client Serveur/MT.pdf
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é.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Rhaegar . Évalué à 0.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Mr F . Évalué à 1.
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 . É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.
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 (site web personnel) . Évalué à 1.
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
Posté par #3588 . Évalué à 1.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par anonyme512 . Évalué à 1.
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
Posté par pini . Évalué à 3.
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 ?
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par pini . Évalué à 1.
Je retourne me coucher...
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Foxy (site web personnel) . Évalué à 1.
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 . Évalué à 3.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 2.
http://pmk.sourceforge.net/(...) <= la
voila voila
pm
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Envoyé depuis mon PDP 11/70
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Envoyé depuis mon PDP 11/70
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par megablorb . Évalué à 1.
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 . Évalué à 0.
# Pour plus d'info sur la gestion de configuration/version et le libre
Posté par Jetto . Évalué à 2.
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 . Évalué à 3.
[^] # Re: Pour plus d'info sur la gestion de configuration/version et le libre
Posté par Nÿco (site web personnel) . Évalué à 1.
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).
[^] # Re: Pour plus d'info sur la gestion de configuration/version et le libre
Posté par Jetto . Évalué à 4.
# Re: Comparatif des systèmes de contrôle de version
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
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 ?
"La première sécurité est la liberté"
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Foxy (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 1.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par free2.org . Évalué à 2.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par jmfayard . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par jmfayard . Évalué à 3.
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
Posté par Dugland Bob . Évalué à 1.
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
Posté par Malrog Malrog . Évalué à 1.
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 . Évalué à 2.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par #3588 . Évalué à 3.
[^] # Re: Comparatif des systèmes de contrôle de version
Posté par Philippe F (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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
Posté par beny (site web personnel) . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Format de stockage
Posté par Éric (site web personnel) . Évalué à 1.
# Re: Comparatif des systèmes de contrôle de version
Posté par ckyl . Évalué à 1.
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).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.