Subversion est un système de contrôle de révision, développé dans le but de remplacer CVS comme norme du contrôle de révision dans le monde du libre. La version 1.0 est sortie au terme de 5 ans de conception et développement sponsorisé par l'entreprise Collabnet, et regroupe maintenant une communauté très active. Un grand nombre de projets libres importants ont depuis migré vers Subversion et depuis quelques mois le grand hébergeur Sourceforge propose un hébergement sur Subversion, en remplacement de CVS.
Les avancées majeures de cette version sont l'apparition de l'outil svnsync pour synchroniser des dépôts, le support de BerkeleyDB 4.4 et des performances grandement améliorées aussi bien coté client que serveur. Et bien entendu, un nombre d'améliorations mineures et de corrections de bugs. Résumé des améliorations
L'amélioration la plus visible pour les utilisateurs est sans doute l'apparition d'un nouvel outil, svnsync. Comme son nom semble l'indiquer, cet outil permet de créer des miroirs d'un dépôt Subversion, et de gérer la synchronisation de ces dépôts. Ce n'était possible jusqu'a présent qu'en utilisant des scripts qui ne pouvaient pas garantir l'atomicité des opérations, et qui comportaient beaucoup de bidouilles pour permettre de synchroniser de façon fiable. Svnsync utilise une nouvelle API qui permet de s'affranchir de ces bidouilles, et qui sera sans aucun doute très appréciée par d'autres projets ayant besoin de reproduire à distance des copies parfaites d'un dépôt.
L'autre bonne nouvelle, pour les administrateurs de dépôts cette fois, concerne les dépôts utilisant une base BerkeleyDB: Subversion 1.4.0 supporte maintenant BerkeleyDB 4.4. Cette nouvelle version résout le plus gros problème qu'ont les administrateurs de dépôts BDB, en gérant automatiquement le rétablissement d'un dépôt qui a souffert d'une déconnexion brutale. Exit donc les utilisations répétées de 'svnadmin recover' pour faire taire les erreurs suite à une opération malheureuse, BDB le fera tout seul lors de l'opération suivante.
Enfin, pour l'utilisateur et l'administrateur, Subversion 1.4.0 est une version focalisée sur la performance.
- Coté client, les fichiers .svn/entries ne sont plus en XML, et la copie de travail stocke plus intelligemment les propriétés des fichiers. Il en résulte un client Subversion capable de parcourir la copie de travail plus rapidement et efficacement. Le nombre d'inodes requis pour gérer une copie de travail est aussi réduit, pour le plus grand bonheur de développeurs travaillant sur de gros arbres de code source ;
- Coté serveur, le format de stockage des deltas entre versions a été revu, et il en résulte un gain important de place, pouvant aller jusqu'a 50% de poids perdu pour certains fichiers. Il est par contre nécessaire d'effectuer un cycle svnadmin dump/svnadmin load pour pouvoir tirer parti de cette amélioration, sinon Subversion continuera d'utiliser l'ancien format de deltas.
Les autres améliorations moins vastes que l'on peut trouver sont:
- Le serveur svnserve peut maintenant fonctionner comme service (équivalent d'un daemon unix) sous Microsoft Windows, sans avoir à recourir à des scripts externes ;
- Sur MacOS X, le client svn utilise KeyChain pour stocker son cache de mots de passe au lieu de .subversion/auth/ ;
- Le moteur de diff interne à Subversion peut maintenant ignorer les différences en nombres d'espaces/tabulations et en formats de fin de ligne, pour des diffs qui vont à l'essentiel de ce qui a véritablement changé ;
- Les commandes 'svn diff' et 'svn merge' ont une nouvelle option permettant de demander le diff/la fusion d'une seule révision: 'svn diff -c 1234' est l'équivalent de 'svn diff -r1233:1234'.
L'avenir
Avec son adoption par Sourceforge, et plus récemment par Google pour son hébergement de projets libres, Subversion s'établit de plus en plus comme le remplaçant de fait de CVS. Ce n'est pas une raison pour se reposer sur ses lauriers, et les développeurs ont une assiette bien remplie pour l'avenir.
Dans quelques semaines se tiendra le premier SVN Summit. Hébergé par Google en Californie, cette rencontre sera l'occasion pour beaucoup de ces développeurs de se rencontrer pour la première fois (!), et de discuter sur la future direction de Subversion.
L'un des grands sujets du sommet est le support de suivi de branches ("Merge Tracking"), fonctionnalité réclamée depuis longtemps et déjà bien avancée dans la version de développement. Les autres sujets de discussion sont très variés, allant d'une refonte du schéma de représentation d'historique à des témoignages sur des utilisations ésotériques de Subversion.
Il y sera également question de la roadmap vers Subversion 2.0, la première version qui pourra se permettre de briser la compatibilité avec les versions 1.x pour améliorer la structure du logiciel et y faire un grand ménage, corrigeant des problèmes qui n'avaient pu être adressés avant à cause de la politique de compatibilité agressive du projet.
Aller plus loin
- L'annonce officielle (5 clics)
- Le site du projet (9 clics)
- Les Release Notes (5 clics)
# A noter
Posté par _Hitek_ (site web personnel) . Évalué à 1.
[^] # Re: A noter
Posté par David Anderson . Évalué à 1.
# Contrôle de révision.
Posté par Yth (Mastodon) . Évalué à 10.
Enfin au moins je ne comprend pas ce qui peut se cacher derrière ce terme de "cntrôle de révision", pour moi ça ne veut rien dire.
Franchement, mieux vaut soit laisser le terme anglais, soit utiliser une traduction convenable en français, sinon il faut vaguement retraduire littéralement en anglais pour comprendre...
D'ailleurs, une bonne traduction se trouve aisément, tu as mis directement un lien wikipédia vers "contrôle de révision" qui redirige vers la page de "gestion de versions" qui sans être une manière transcendante de décrire le logiciel, à l'avantage d'être compréhensible, en français.
Yth.
[^] # Re: Contrôle de révision.
Posté par David Anderson . Évalué à 4.
Notons néanmoins que "gestion de versions" peut induire en erreur, parce qu'on utilise souvent "version" pour parler de sorties stables d'un logiciel, plutot que les changements incrémentaux qui prennent place pendant le développement. C'est pour cela que Subversion préfère en anglais "revision control", plutot que le "version control" que CVS utilisait.
Alors, "gestion de révisions" ? Moyen encore, puisque ca peut se comprendre comme "outil pour gérer son bac". La langue française est mal fichue des fois :-)
[^] # Re: Contrôle de révision.
Posté par gnu_thomas . Évalué à 0.
des problèmes qui n'avaient pu être adressés
est un anglicisme.
Enfin, on pinaille car ta news est claire et complète :)
[^] # Re: Contrôle de révision.
Posté par Prsieux . Évalué à 2.
# Vous devez entrer un sujet
Posté par Troy McClure (site web personnel) . Évalué à 10.
Encore une belle preuve de l'aberration totale qu'est XML ... Quand j'entends que certains intaigristes veulent farcir /etc avec ce truc je perds tout espoir dans le genre humain.
[^] # Re: Vous devez entrer un sujet
Posté par Philippe F (site web personnel) . Évalué à 6.
[^] # Re: Vous devez entrer un sujet
Posté par boubou (site web personnel) . Évalué à 10.
Il ne faut pas confondre l'outil et son utilisation. XML est un outil très utile, il faut simplement refléchir à son impact au lieu de le choisir systématiquement.
[^] # Re: Vous devez entrer un sujet
Posté par Stéphane Klein (site web personnel) . Évalué à 4.
Par exemple, si vous configurez un fichier à la "main" puis utilisez webmin pour configurer ce même fichier, votre fichier de configuration n'aura plus la même "tête".
Enfin, cela est mon analyse... peut être que je mon trompe... à vous de m'expliquer pourquoi.
[^] # Re: Vous devez entrer un sujet
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Bref, il y a d'autres format que le XML qui sont aussi bien fichu.
Si tu te balades dans le CPAN, tu verras que tous les modules Perl ont maintenant un fichier YAML pour les décrire.
Mon choix est vite fait personnellement, je fais tous mes fichiers de configuration en YAML depuis que je l'ai découvert.
[^] # Re: Vous devez entrer un sujet
Posté par boubou (site web personnel) . Évalué à 2.
Ca ne fait pas l'ombre d'un doute. Par contre, aucun format n'est aussi populaire que XML et aucun format ne propose donc une telle quantité d'outils associés. Je ne parle pas simplement de bibliothèques chargement/sauvegarde, mais aussi de tout le reste (validation de schéma, transformation, langage de requête, etc.).
[^] # Re: Vous devez entrer un sujet
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ici, pour subversion, il a l'air de s'agir essentiellement de sauver et recharger, par une seule application. Donc autant prendre un truc plus rapide que XML au moment ou l'API est stabilisé et marche.
Au niveau de YAML, j'aime bien l'exemple du CPAN car c'est un GROS machin avec des dépendances dans tous les sens et les fichiers descriptifs en YAML ont l'air de convenir à tous. Tant mieux.
[^] # Re: Vous devez entrer un sujet
Posté par lolop (site web personnel) . Évalué à 5.
http://www.yaml.org/
http://www.json.org/
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Vous devez entrer un sujet
Posté par arnaudus . Évalué à 4.
Parfois, il est préférable de perdre en performances à des fins d'interopérabilité, et je pense que c'est clairement le cas des fichiers de conf.
[^] # Re: Vous devez entrer un sujet
Posté par BAud (site web personnel) . Évalué à 4.
C'est un format binaire pour lequel de nombreuses bibliothèques sont disponibles pour le rendre lisible et qui a l'avantage d'avoir une grammaire extensible et normalisée.
[^] # Re: Vous devez entrer un sujet
Posté par boubou (site web personnel) . Évalué à 0.
[^] # Re: Vous devez entrer un sujet
Posté par BAud (site web personnel) . Évalué à 2.
L'ASN/1 a été optimisé pour la place prise, je me serais mal vu avec des tickets de taxe remontés des MSC (autocommutateurs dans le monde mobile) en XML... déjà que notre élément de médiation croulait parfois (rarement quand même) sous le nombre de TTfiles, si en plus la volumétrie avait été non optimisée /o\ (sachant que ce sont les I/O disques qui limitaient les perfs...). Un week-end nous avait permis de rattrapper un mois de consommations à une époque... (oui oui ça dépotait ;-) )
[^] # Re: Vous devez entrer un sujet
Posté par arnaudus . Évalué à 2.
Il faut que tu m'expliques en quoi ton format binaire 'achement vien foutu est tellement supérieur à XML qu'il peut se permettre d'imposer à l'utilisateur d'installer un soft pour le lire.
Parce que pour moi, la possibilité de se priver de
vi ~/.toto
:%s/blue/red/g
:wq
a un coût gigantesque.
Et XML, c'est, je paraphrase, C'est un format binaire texte pour lequel de nombreuses bibliothèques sont disponibles pour le rendre lisible et qui a l'avantage d'avoir une grammaire extensible et normalisée.
Ma (faible, je l'accorde) expérience m'incite à penser que la seule raison valable pour abandonner un format XML bien foutu, c'est quand les fichiers deviennent trop gros et que les accès sont trés fréquents, auquel cas il faut se tourner vers une structure de type base de données. Mais passer d'XML à un format binaire, ça me semble être un retour à la préhistoire. Même si je sais que mon opinion n'est pas vraiment partagée, je pense qu'un des avantages du gain de performances des machines, c'est aussi qu'on peut se passer de micro-optimisations désastreuses pour l'ergonomie et le développement.
[^] # Re: Vous devez entrer un sujet
Posté par Nicolas Schoonbroodt . Évalué à 1.
bash: vi: command not found
Faut aussi installer un logiciel pour lire/écrire du xml de façon simple... Bon après c'est sur que c'est un seul éditeur de texte pour tous les fichiers xml, contre un par type de format binaire.
[^] # Re: Vous devez entrer un sujet
Posté par Barnabé . Évalué à 0.
(Mauvaise Foi Évidente)
[^] # Re: Vous devez entrer un sujet
Posté par reno . Évalué à 5.
Donc cela me parait plutot une bonne idée de commencer par un format XML et s'il s'avere que c'est un probleme au niveau performance de remplacer par un format binaire.
C'est comme de commencer par developper en Ruby et remplacer si nécéssaire certaines parties par du C: une stratégie intelligente de developpement.
[^] # Re: Vous devez entrer un sujet
Posté par boubou (site web personnel) . Évalué à 2.
Tu parles des schémas du W3C ou en général ? Parce que franchement, les schémas Relax NG, je ne vois pas en quoi ils sont mal fichus, au contraire.
[^] # Re: Vous devez entrer un sujet
Posté par reno . Évalué à 2.
[^] # Re: Vous devez entrer un sujet
Posté par David Anderson . Évalué à 6.
Malheureusement, lors du développement de Subversion, le XML s'était aussi infiltré dans des fichiers qui ne sont lus que localement. L'idée était de pouvoir changer incrémentalement de format aisément, et de profiter de bibliothèques de lecture/écriture déjà très développées et performantes.
L'optimisation consistant à changer le format est venue suite à un effort de rendre toute la bibliothèque de gestion de copie de travail "streamy", c'est à dire opérant le plus possible sur des flux et des transformations de ces flux, plutot que sur le modèle "tout charger, modifier, tout ecrire". Et c'est là qu'un problème du XML se manifeste: il est difficile de lire seulement une partie d'un fichier sans d'abord tout charger pour avoir le DOM.
Le nouveau format s'affranchit partiellement de ce problème. De plus, maintenant que les métadonnées de copie de travail sont stabilisées et établies, l'extensibilité que promettait le format XML n'est plus vraiment utile. Une extensibilité plus limitée nous suffira jusqu'a Subversion 2.0.
Voila pour le raisonnement derrière tout ca.
[^] # Re: Vous devez entrer un sujet
Posté par Christophe Fergeau . Évalué à 1.
Je suis pas certaind e t'avoir bien compris, ie soit vous avez eu des pbs spécifiques au format choisi par svn qui vous obligeait à tout charger, auquel cas, c'est plus votre pb à vous qu'un pb de svn, soit tu te plains qu'en utilisant un parser xml DOM, on est obligé de tout charger, et là c'est un peu comme si tu disais "le pb avec un langage compilé, c'est qu'on est obligé d'avoir un compilateur avant de pouvoir exécuter le code".
Enfin tout ça pour dire qu'il y a des parsers XML permettant de ne parser qu'une partie du fichier et de t'arrêter quand tu en as envie, cf http://xmlsoft.org/xmlreader.html
Par contre, il est fort possible que si tu veux parser une partie du fichier, puis en réécrire uniquement une partie, alors ça ne soit pas super facile à faire.
# Bouquins sur Subversion
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 10.
O'Reilly propose la traduction francaise du "SVN Book", Version Control with Subversion, intitulé en francais "Gestion de projets avec Subversion". http://www.oreilly.fr/catalogue/2841772691.html
C'est un livre très théorique, relativement complet. Sorti en novembre 2004 et donc basé sur la version 1.2 de Subversion. Vous pouvez vous faire une idée du contenu (en anglais par contre) sur le site http://svnbook.red-bean.com/en/1.2/index.html car le SVN Book est sous licence CC-by il me semble. (à vérifier par les experts sur http://svnbook.red-bean.com/en/1.2/svn.copyright.html ). Le passage à la version papier est plutôt réussi.
Quant à Eyrolles, le livre "Subversion, Pratique du développement collaboratif avec svn" http://www.editions-eyrolles.com/Livre/9782212119190/subvers(...) est lui aussi une traduction d'un livre anglais, celui de Mike Mason "Pramatic version control using Subversion. Il prends une orientation différente du livre précédent: il est plus axé pratique avec quelques cas d'utilisations concrets décrits (ce n'est pas pour autant un cookbook !). Il va moins dans les détails et les subtilités mais donnera toutes les clefs pour une utilisation quotidienne et une aide à l'administration. La version anglaise se base sur la version 1.2, mais lors de la traduction, les traducteurs ont mis à jour pour une utilisation en 1.3
Personnellement, pour avoir lu les deux, je recommanderais l'Eyrolles à quelqu'un qui débute ou n'a que quelques notions d'un gestionnaire de version et j'orienterais l'utilisateur quotidien de CVS ou autre outil similaire vers l'O'Reilly.
[^] # Re: Bouquins sur Subversion
Posté par David Anderson . Évalué à 3.
Bref, les deux ont leur utilité. Je recommanderais également le Eyrolles à des gens cherchant une introduction à Subversion. Pour ceux qui veulent un ouvrage de référence, l'Oreilly est à préférer. Sa version originale en anglais est disponible sur le web, sous une licence creative commons: http://svnbook.red-bean.com/ .
# Compatibilité ascendante
Posté par Samuel Verschelde (site web personnel) . Évalué à 5.
Faut-il toujours une équivalence entre la version du serveur et celle des clients, ou est-ce que c'est assez souple ?
[^] # Re: Compatibilité ascendante
Posté par David Anderson . Évalué à 3.
Donc, ton client 1.4 peut sans problèmes communiquer avec un serveur 1.1.4. Bien entendu, les fonctionalités coté serveur seront limitées à celles présentes dans Subversion 1.1, et tu ne bénéficieras pas de quelques optimisations du protocole de communication. Mais tout devrait toujours fonctionner, sinon c'est une régression.
Le jour ou Subversion 2.0 sortira, il n'y a aucune promesse autre que "Il sera possible de passer de 1.x a 2.0 d'une façon ou d'une autre". Les clients 1.x ne pourront vraisemblablement pas communiquer avec un serveur 2.0.
[^] # Re: Compatibilité ascendante
Posté par Samuel Verschelde (site web personnel) . Évalué à 0.
# OpenCVS
Posté par spotty . Évalué à -1.
a) CVS est largement utilisé et tout le monde ne vas pas passer à subversion
b) un projet OpenCVS est démarré chez openBSD, qui paraît-il va être utiliser pour les sources d'openBSD.
[^] # Re: OpenCVS
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 5.
Le but de Subversion est de fournit un remplacant inconstestable à CVS, pas de démarcher les projet pour leur demander de changer et d'abandonner CVS en le remplacant par SVN.
Ils offrent le choix en proposant une alternative proche (pour simplifier, on peu facilement remplacer cvs par svn dans les commandes) et comblant les lacunes du premier à la communauté Open Source. En effet, beaucoup de solutions propriétaires offraient des solutions de gestion de fichiers puissantes et fonctionnelles avec peu ou pas d'équivalent dans le monde du libre.
je cite le site de subversion : "The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community."
Le projet OpenCVS est une réécriture, à fonctionnalités équivalentes, de CVS ayant pour objectif d'avoir une solution sécurisée et maintenue par rapport au CVS actuel qui est un peu délaissé.
cf. http://www.opencvs.org/index.html et http://linuxfr.org/~patrick_g/16411.html
La formulation de la déppêche est un peu brute effectivement, mais je pense que la vérité est quelque part au milieu, ou ailleurs...
[^] # Re: OpenCVS
Posté par patrick_g (site web personnel) . Évalué à 7.
Tout le monde non mais y'a quand même du lourd qui a basculé :
KDE est passé à Subversion.
Gnome est passé à Subversion.
GCC est passé à Subversion.
Python est passé à Subversion.
[^] # Re: OpenCVS
Posté par spotty . Évalué à -5.
Bon, soyons sérieux maintenant, KDE, gnome, GCC... sont des gros projets mais ce ne sont pas tous les projets opensources qui existent.
subversion n'est pas le remplaçant de CVS, certains projets le choisiront, d'autres non, d'autres utiliseront d'autres produits (openCVS, gits...) Arrêtez de dire que subversion est le remplaçant de CVS, ce n'est pas vrai : les concepts, commandes, possibilités et façon d'utiliser dont différents. Les utilisateurs intensif du branch/merge ne trouvent pas encore leur bonheur sous subversion.
Et puis, pourquoi voulez-vous qu'un soft en élimine un autre ?? MS déteint sur vous ou quoi ???
Moinssez moi, c'est si facile et anonyme
[^] # Re: OpenCVS
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
bah je ne sais pas mais pour moi, ça l'est quand même hein : c'est le même type de gestionnaire de version. Il en reprend la majorité des commandes, mais en plus simple. À la différence que svn est plus performant, les rapports de log, d'history &cie sont beaucoup plus clairs, la doc est vraiment mieux foutu, la numérotation des commits ultrasimple (et pas des numeros à 15 chiffres et points), et svn corrige des lacunes de svn (historisation des renomages/deplacements par ex..) etc..
Quand on a fait du CVS, passer à SVN est du pure bonheur. Il y a juste cette nouvelle "vision" des branches/tags, et la disparition des modules qui peuvent perturber au début, mais personnellement, je m'y suis adapté trés vite.
> pourquoi voulez-vous qu'un soft en élimine un autre ??
parce que c'est ce qui se passe en vrai dans la vrai vie du monde réèl... C'est un constat, pas une affabulation.
[^] # Re: OpenCVS
Posté par David Anderson . Évalué à 10.
Quant à la remarque sur l'utilisation intensive du branch/merge, j'avoue ne pas comprendre, a moins que tu n'aie jamais utilisé CVS. La gestion des branches dans CVS est l'une des pires facettes de ce logiciel. J'admets, il n'y a pas encore de merge tracking intégré à Subversion, mais d'un autre coté, dans CVS non plus. C'est un affreux hack qui ne garantit en rien l'intégrité des données. Le développement du merge tracking dans Subversion avance, et en attendant, l'outil svnmerge.py implémente les trois quarts de ce qui est nécessaire pour le commun des mortels de ce coté là.
OpenCVS, sans vouloir lancer de troll, je me demande si ca servira à quiconque autre qu'OpenBSD. Rester coincé sur la compatibilité avec "l'outil d'avant" est l'erreur que CVS a fait en se basant sur RCS, et RCS sur SCCS. Ils ont trainé des erreurs de conception sur plus de 20 ans avec ce principe, et OpenBSD veut maintenant les perpétuer dans son propre projet.
Ce n'est pas pour rien à mon avis que tant de projets se détachant du code de CVS sont nés. CVS est dans l'impasse depuis 2000, mis a terre par sa compatibilité ascendante à outrance, trainant plus de 20 ans d'erreurs, refusant obstinément de changer pour préserver une compatibilité qui n'a plus lieu d'être. Le monde s'est rendu compte que c'était une impasse, et a commencé a bosser sur d'autres produits: bitkeeper dans le monde propriétaire, et une constellation d'outils dans le monde libre. Bon sang, les développeurs les plus actifs de CVS à l'époque ont déserté pour écrire Subversion, ça devrait envoyer un message clair!
Concernant les autres outils existants, moi je dis bravo. Gits, TLA, Mercurial, Darcs, Codeville, tout ca, bravo. Ce sont des projets intéressants, plus ou moins avancés, mais intéressants. Ils cherchent tous à faire avancer le monde en proposant des outils performants, et font avancer la théorie du revision control en général. Et ils n'ont pas peur de dire "Non, on ne va pas etre compatible avec le format de dépot tout à fait pourri de CVS. On va oser changer la tronche de l'interface utilisateur, parce qu'on pense pouvoir faire mieux."
Désolé de m'emporter, mais en tant que développeur et passioné d'outils de revision control, CVS m'a traumatisé, et le fait qu'on puisse en 2006 prétendre que cet outil à un avenir autre que la casse me fait voir rouge.
[^] # Re: OpenCVS
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Subversion c'est CVS, mais en _mieux_ (inutile de lister les améliorations une nième fois, j'espère). Et c'est pour ça qu'il est présenté comme son remplaçant.
[^] # Re: OpenCVS
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
Et ils commencent à faire des tests avec subversion :
http://weblogs.mozillazine.org/preed/2006/08/subversive_subv(...)
Et personnellement, tous mes projets persos sont sous subversion. Il y a longtemps que j'ai dit au revoir à CVS (qui suxor, rappelons-le)...
[^] # Re: OpenCVS
Posté par Boa Treize (site web personnel) . Évalué à 3.
[^] # Re: OpenCVS
Posté par Vivi (site web personnel) . Évalué à 3.
non pas encore, il y a eu des problèmes lors de la migration est c'est repoussé pour l'instant.
# Merge tracking
Posté par golum . Évalué à 4.
Vous êtes sur de ça ?
Sur la roadmap:
http://subversion.tigris.org/merge-tracking/
Et si on se rend sur les specs
http://subversion.tigris.org/merge-tracking/requirements.htm(...)
on se rend compte des limitations actuelles.
- risque de doublons ou d'effacement lors des merges répetés
- pas d'historisation des renommages de répertoires ce qui fait qu'il est impossible de maintenir 2 arborescences qui auraient divergé
- pas d'assistant de merge d'arborescence entière.
Lorsqu'un projet doit faire évoluer son architecture dans le cadre d'une migration technique ou d'un changement au niveau du métier c'est très pénalisant
J'évalue actuellement l'opportunité pour ma boîte de remplacer Clearcase SVN en tant qu'outil de GCL par défaut pour les projets, mais de telles limitations me paraissent rédhibitoire. Son usage en l'état ne pourra être envisagé que pour des petites équipes.
David, toi qui semble suivre les discussions sur le sujet peux-tu nous apporter quelques précisions ou un pointeur.
[^] # Re: Merge tracking
Posté par Geo Vah . Évalué à 2.
Typiquement, ou je bosses, il n'est utiliséque en vue dynamique et là c'est impossible à le remplacer...
[^] # Re: Merge tracking
Posté par golum . Évalué à 2.
L'interêt des vues dynamiques, c'est uniquement pour les dev type C/C++ ou tu peux bénéficier du partage d'objets dérivés et du clearmake (audit de fabrication, detection autmatique des cibles , optimisations parallèles, ...) ou pour les devs cross plateformes ou tu uilses un IDE windows et que tu compiles et teste sous Unix.
Avec les outils de fabrication d'aujourd'hui et les dernières evolutions des compilos c'est de moins en moins interessant.
Pour les autres cas ca n'a guère d'intêret d'autant que les vues dynamiques ont pas mal d'inconvénients par ailleurs.
[^] # Re: Merge tracking
Posté par golum . Évalué à 2.
Déjà ils n'utilisent pas CC (Eclipse et WSAD sont sous CVS, ...) et ca fait longtemps qu'il on perdu les sources du noyau de CC (quand il l'on auto-hosté) et c'est pour ca qu'il ne le font jamais évoluer mais préfèrent faire tout leur buzzword avec la surcouche UCM. Ceux qui se sont dèjà battu avec des fichiers corrompus par des lignes avec des Ctrl M et d'autres sans me comprendront.
[^] # Re: Merge tracking
Posté par Geo Vah . Évalué à 1.
[^] # Re: Merge tracking
Posté par golum . Évalué à 2.
UCM Clearcase et ClearQuest outillent le processus UCM qui s'inscrit dans la méthodologie RUP.
Il n'en demeure pas moins que c'est une rustine aux lacunes de Clearcase (c'est grâce à la couche UCM que Clearcase bénéficie de la notion de changeset qui n'existent pas dans noyau. ...). Dans certains cas l'héritage est même pénalisant. Par exemple tu as une branche par développeur (stream developpeur) et pourtant tu es toujours obligé d'extraire tes fichiers avant de le modifier. Quel est l'intêret ? La reservation sert juste à prevenir les autres developpeurs que tu travailles sur le fichier. Là ils ne travaillent pas sur la mme branche ^dons ils s'en moquent un peu.
Si tu veux affecter une activité que tu as démarré (une demande de changement) à quelqu'un d'autres tu es obligé de la rendre mais comme tu as commité tu ne peux pas revenir en arrière sasn faire un merge (un autre outil
te ferait un simple revert de ton workspace). J'en passe et des meilleures
Il n'y a pas besoin d'UCM Clearcase/Clearquest pour faire de l'UCM. C'est juste un processus et je vais peut-être etudier sa transposition avec SVN/Trac si ce n'est déjà fait quelquepart.
[^] # Re: Merge tracking
Posté par David Anderson . Évalué à 4.
Concernant le remplacement de Clearcase par Subversion, je dois être franc et te dire que ça va être difficile. Clearcase est plus, bien bien plus, qu'un simple outil de revision control. Il incorpore toute une floppée d'autres aspects du cycle de développement. De plus, son UI est très différente de tous les autres outils existants, ce qui va rendre la migration vers autre chose difficile.
Donc, je serais de l'avis de commencer, comme tu le suggères, par des petites équipes pilotes. Etudiez les problèmes de migration qu'il y a sur un petit projet, pour mieux planifier une éventuelle migration totale.
À noter également que Collabnet, l'entreprise qui est à l'origine de Subversion, propose des solutions plus complètes se basant sur Subversion, qui pourraient éventuellement remplacer plus efficacement l'intégralité de Clearcase. Disclaimer: Je ne suis pas employé de Collabnet, je n'ai jamais déployé leurs systèmes en entreprise. J'en ai simplement entendu du bien, et il est clair qu'ils rassemblent encore à ce jour une grande expertise sur Subversion, qu'aucune autre entreprise ne peut à ce jour prétendre égaler.
Si tu as besoin d'aide pour la migration, n'oublie pas la liste de diffusion users@subversion.tigris.org, ou tu trouveras peut-être d'autres gens qui ont fait des migrations depuis Clearcase. Et dans tous les cas, que ce soit un succès ou non, n'oublie pas de nous rapporter le résultat de cette étude/migration, ça nous intéresse!
[^] # Re: Merge tracking
Posté par golum . Évalué à 2.
J'espère que tu nous feras un petit débriefing dans une dépêche.
Pour le reste je suis d'accord avec toi en partie mais je connais assez le domaine pour te dire que CC en tant qu'outil de gestion de configuration (GCL ou SCM) [1] est dépassé. En plus, l'appellation "outil SCM" varie beaucoup d'un éditeur à l'autre. CC seul ne propose pas la gestion des changements qui fait partie de la GCL car il n'offre même pas la notion de changeset. De même la gestion des release en fonction des plateformes n'entre pas dans son périmètre (cf. SpectrumSCM) ou encore celle du déploiement (Endevor)
En combinant diverses solutions open source et tu peux arriver à un resulat équivalent voire meilleur pour bien moins cher (le service ne coutera jamais aussi cher que le cumul du prix des licences et du support)
En tant qu'outil de contrôle de version (il apparait comme ca sur wikipédia [2]) CC offre plein de fonctionnalités que SVN ne propose pas (merge tracking, gestion des composants avec UCM, triggers coté client sur nb d'opérations, vues dynamiques, multisite, algorthmes de stockage de comparaison et de merge par type de fichiers, ...)
Mais avec l'evolution des technologies elles sont de moins utiles et l'architecture du produit devient un vrai handicap et les plus essentielles sont sur la roadmap SVN.
[1] http://en.wikipedia.org/wiki/Software_configuration_manageme(...)
[2]
http://en.wikipedia.org/wiki/List_of_revision_control_softwa(...)
# Outil de diff/merge
Posté par MetalX . Évalué à 1.
Personnellement, j'utilise kdiff3, mais j'ai un peu de mal avec l'édition manuel des conflits. ( J'ai auparavant eu à travailler surtout avec le merge de ClearCase et BeyondCompare, et depuis je peine à trouver qqch d'aussi bien )
[^] # Re: Outil de diff/merge
Posté par Philippe F (site web personnel) . Évalué à 4.
Bon, ca marche que sous windows, mais c'est opensource :-)
[^] # Re: Outil de diff/merge
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
# Enfin !!
Posté par gaston . Évalué à 2.
Enfin, on va pouvoir avoir des diffs lisibles. j'en peux plus de recevoir des messages de commits contenant des diffs constitués pour 95% de changements d'indentation, tout ca à cause d'éditeurs différents/mal configurés/style d'indentation non communs.
La guerre sur les styles d'indentation par défaut de vim/emacs va peut-être prendre fin. Si seulement tout le monde pouvait utiliser indent, et se mettre d'accord sur un style commun...
[^] # Re: Enfin !!
Posté par lolop (site web personnel) . Évalué à 5.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Enfin !!
Posté par golum . Évalué à 3.
[^] # Re: Enfin !!
Posté par oliv . Évalué à 3.
[^] # Re: Enfin !!
Posté par lolop (site web personnel) . Évalué à 2.
Bonne forme + bon fond = que du bonheur.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Enfin !!
Posté par rewind (Mastodon) . Évalué à 5.
[^] # Re: Enfin !!
Posté par arnaudus . Évalué à -3.
Évidemment, la tâche n'est pas simplifiée par les langages à la con qui accordent un sens à des caractères invisibles (ou pire: à la répétition de caractères invisibles, comme les doubles sauts de ligne en Latex). Je pense qu'on devrait retrouver les types qui ont mis au point ces langages, leur couper les couilles, les faire frire et leur faire bouffer.
Sans déconner, est-ce que vous pourriez estimer la perte de productivité de l'humanité toute entière due aux milliards d'heures perdues par des devs à réaligner du code, à discuter sans fin de conventions de codage ou à débogguer un Makefile dans lequel un esprit de l'axe du Mal(TM) a remplacé une tab par des espaces?
[^] # Re: Enfin !!
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
A ma connaissance, quasiment tout le monde trouve très bien les fins de lignes. D'ailleurs, le C++ a bien rajouté // pour faire des commentaires (jusqu'a la fin de ligne) car les commentaires du C n'était pas idéal dans plein de cas (pas pour rien que presque tous les langages ont un(deux) caractères qui marque les début des commentaires : # pour les langages de scripts, -- en ada, ; fichier de conf DNS...
Ensuite, dans les langages impératifs, le saut de ligne marque en général le passage à l'instruction suivante, c'est tout à fait naturel.
Par ailleurs, je ne partage pas du tout ta critique de LaTeX du double saut de ligne pour changer de paragraphe. C'est encore une fois tout à fait naturel et particulièrement facile à relire (bien plus que le </p> !)
Par contre, les tabulations sont une plaie, surtout dans les fichiers de conf (makefile, rsnapshot). Je ne comprends pas pourquoi les deux caractères '->' en début de ligne dans un Makefile ne soit pas équivalent à la tabulation. On aurait ainsi une évolution en douceur et compatible des Makefiles vers quelque chose de bien plus maintenable sur le long terme.
En conclusion, j'aime bien que le source soit sous un format basique que je puisse imprimer facilement. Je n'ai pas envie d'être obliger d'avoir un éditeur particulier pour avoir une mise en page lisible. Avec un tel système, on finirait par avoir un éditeur par langage ! Il ne faut pas lier un langage de programmation avec l'éditeur ou le système sera trop contraint pour évoluer. Je le vois bien avec les Windowsiens qui arrivent sous linux et sont perdus car ils n'ont pas leur VisualStudio. Que diable, ils peuvent bien éditer avec l'éditeur qu'ils préfèrent et lancer "make" dans le shell à coté. Une fois qu'ils ont compris cela, ils commencent à saisir un petit peu la souplesse d'une machine de type UNIX.
[^] # Re: Enfin !!
Posté par arnaudus . Évalué à 3.
Utiliser un éditeur de texte qui ne sait pas lire le code, par exemple Word, pour lire un fichier C, ne rendrait pas le truc illisible :
int main(int argc,char** argv){printf("Hello Word!\n");}
reste quelque chose de "compréhensible" (bon, c'est sûr, si le fichier fait 200ko, ça va être moins lisible...). Mais ça reste du texte, et ça ne compromet en rien la lecture, la modification, la recherche de chaines de caractères etc. Mais la mise en page est neutre, et c'est à l'éditeur de texte, si l'utilisateur le veut, de remettre ça en page pour faciliter la lecture et l'édition. Donc je persiste à dire par exemple qu'en C, le saut de ligne est un caractère de mise en forme, il n'a aucun sens (autre que celui de séparateur, et malheureusement, de fin de commentaire pour les // du C++). Au passage, cette "suppression de tous les caractères inutiles avant publication" est courante pour le HTML, je ne vois pas pourquoi ça ne pourrait pas se faire pour les autres languages.
L'informatique n'échappe pas à la tendance naturelle à l'immobilisme : si un gars s'est fait chier 20 ans avec les Makefile merdiques, il va voir d'un mauvais oeil l'apparition d'une nouvelle syntaxe qui va tout révolutionner.
[^] # Re: Enfin !!
Posté par rewind (Mastodon) . Évalué à 4.
et là tu as l'air très bête si tu as tout sur la même ligne...
Pour un compilateur, certes, les sauts de ligne ne veulent rien dire (et encore, cpp geulent s'il n'a pas son fin de ligne à la fin du fichier). Mais nous sommes des humains, et nous utilisons des outils simples qui permettent d'afficher des sauts de lignes alors on en profite.
[^] # Re: Enfin !!
Posté par arnaudus . Évalué à 5.
Error: helloworld.c:1 : c'est évidemment un bug du compilateur. Ça serait beaucoup plus logique qu'il indique le caractère dans le fichier qui pose problème, et pas la ligne.
Ce que je veux dire, c'est que le système a une inertie terrible : 1) les langages de programmation existants prennent parfois en compte des informations de mise en page du code, 2) les éditeurs savent très mal travailler l'indentation d'un fichier, 3) les programmeurs sont probablement encore plus intertes que le reste de l'humanité, et faire changer ses habitudes à un programmeur, ca doit être au moins aussi stimulant intellectuellement que de faire rentrer des notions de politique internationale dans la tête de G. W. Bush. La conclusion de ça, c'est que dans 30 ans, les fichiers seront encore indentés à la main ou très mal indentés par un éditeur, les languages (comme C++++) prendront toujours en compte des informations de fond pour fabriquer du sens, il faudra toujours un bac +30 pour faire fonctionner les autotools (dont la version 37.8 sera bien entendu incompatible avec la 37.7, elle même incompatible avec la 37.6).
Mais ça me rend juste triste de voir qu'il faut implémenter des workarounds sales dans les svn en 2006 parce qu'il est rigoureusement impossible de comprendre qu'un gusse a remplacé une tab par 8 espaces. Ça me rend aussi triste de voir que des projets comme Gnome ou KDE (et probablement des centaines d'autres) continuent à se prendre la tronche et donc à perdre un temps fou sur la définition de normes pour l'indentation, alors qu'encore une fois ça serait tellement simple si ça pouvait être géré par l'éditeur de chacun, en fonction des préférences de chacun, mais seulement à l'affichage, puisque c'est bien de ça qu'il s'agit, et pas dans le fichier source lui-même. Tout ça parce qu'on traine les erreurs du passé, comme un boulet au pied auquel on est tellement habitué que ça nous ferait presque mal de nous en débarrasser.
[^] # Re: Enfin !!
Posté par Nicolas Schoonbroodt . Évalué à 5.
[^] # Re: Enfin !!
Posté par David Anderson . Évalué à 1.
` svn diff -x '-w' ` produira un diff unifié qui ignore les changements d'indentation. Il me semble qu'il est possible de configurer son client de telle manière qu'il passe systématiquement le -w au moteur de diff interne. Par défaut, le diff est toujours un diff unifié normal, qui montre tous les changements.
A noter que la nouveauté ici est bien que le moteur de diff *interne* de Subversion supporte ces options. Il était déjà possible de dire a `svn diff` d'utiliser un logiciel de diff externe, comme GNU Diff, et lui passer des options similaires.
# Problème des Mac
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je me suis amusé à faire un partage WebDav avec autoversionning subversion. C'est la meilleure méthode que j'ai trouvé pour faire du WebDav avec une gestion, modeste, des droits sur les fichiers (Je dis modeste car il y a quasiment toutes les briques pour faire avec svn la grande mode actuelle : les bureaux virtuels. Mais pour en arrivé là, il faut que le client puisse gérer les droits).
Les utilisateurs montent cela sur leur postes, Windows, Mac, Linux. Et là, le problème des Mac avec la pollution des dossiers que ces bestioles génèrent...
D'où ma question : est-il prévu dans svn d'avoir des hooks tout près à l'emploi qui élimine dès le commit ces fameux, et pour le moins épouvantable, fichier spécifique au Mac ? En effet, je ne dois pas être le seul qui a un repository complètement pollué par ces fichiers.
[^] # Re: Problème des Mac
Posté par Oook . Évalué à 2.
http://docs.info.apple.com/article.html?artnum=301711
Sinon Xcode utilise svn de base, je pense qu'il doit y avoir des outils installables. Je sais que ça existe pour les clés : vu comment OS X traite les montages, ça peut peu-être se transposer...
[^] # Re: Problème des Mac
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Mon unique idée serait donc de mettre en place un hook dans subversion qui analyse la tansaction et vire une partie des fichiers de cette transaction.
Bref, c'est Apple quoi ;-(
# SVN, HTTP et dossier
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Question : pourquoi le XML que le serveur SVN génère a si peu d'information. On a le droit d'avoir en double le nom du fichier, donc une fois de trop, mais pas le poids (taille) du fichier, la personne qui a réalisé la dernière révision, ni la date de modification.... Bref, pas mal d'information accessible facilement en ligne de commande.
Avec ce type d'information, en modifiant un peu le filtre xsl fourni, on pourrait avoir un affichage avec un navigateur du même type que celui que donne Apache d'un dossier. L'utilisateur lambda ne verrait même pas qu'il a affaire à un gestionnaire de version.
C'est aussi cela qui me plait avec SVN, c'est qu'il arrive à se faire oublier et que l'on peut avoir l'impression de travailler sur des dossiers comme les autres.
Dans le même ordre d'idée, un module fuse : "svnfs", me paraît complètement indispensable ;-)
# bazaar
Posté par Mildred (site web personnel) . Évalué à 3.
A un moment, j'ai décidé d'utiliser un système de gestion de révision pour mes projets personnels. Ces projets sont au stade pré-alpha, des choses complètement instables, et surtout beaucoup de projets morts nés.
La gestion de révision m'intéressait surtout car je devais souvent créer des dossier old1, old2 ... conrtenant des anciennes versions de mes sources que je ne voulais pas jeter mais pas non plus garder car je les avaient remplacées par du meilleur code. J'installe alors SVN.
C'était mon premier contact avec un système de gestion de révisions mais jai eu beaucoup de mal, surtout à faire la différence entre le repository et la copie locale. Je ne comprenais pas (et je ne comprend toujours pas) pourquoi les deux choses doivent être séparées.
Depuis, j'ai découvert bazaar-ng et je trouve ca beaucoup mieux car c'est décentralisé (plein d'avantages il paraît) et surtout car je n'ai pas a créer un repository à part. Je peux déplacer mes dossiers de projets sur une autre partition (lorsqu je n'ai plus de place) ... je suis libre.
Je ne nie pas que svn puisse être très utile, surtout pour des projets organisés, mais dans mon coin, c'était très compliqué de gérer tout ça, alors je préfère bzr que je maîtrise beaucoup mieux. je sais où sont mes fichiers et c'est ça qui est important pour moi.
[^] # Re: bazaar
Posté par lolop (site web personnel) . Évalué à 2.
Même en travaillant seul, tu peux avoir à faire plusieurs copies de travail locales. Le repository sert de point commun à ces différentes copies - tu peux très bien supprimer (rm -rf) une copie locale, ça n'aura aucune incidence sur le repository.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: bazaar
Posté par golum . Évalué à 2.
Avec un DVCS (Distributed Version Control System) lorsque je veux récupérer les dernières modif je dois déjà savoir où elle se trouvent (qui détient ce correctif) puis je dois rapatrier ces modifs dans mon repository et puis encore les merger. Que d'étapes
Ensuite je veux envoyer mes modifs et les mêm questions se posent:
A qui les envoyer ?
Dois-je les pusher ou viendra t'on les récupérer chez moi ?
Si je merge les modif de mon voisin chez moi et que lui recupère mes modifs aussi et les merge de son coté on risque de faire le travail en doublon.
Et là les réponse dépendent des outils (head avec monotone) et de l'organisation (un seul intégrateur), des procédures du projet.
Ce qui est révolutionnaire et simplissime quand on est seul devient complexe.
...
Avec un outil centralisé, j'ai une copie à jour du référentiel central, je mets à jour ma copie je travaille, je résoud les conflits et j'envoie.
En outre je ne stocke pas l'ensemble du réferentiel sur mon poste.
Donc effectivement les DVCS ont plein d'avantages lorsque l'équipe est matûre en terme d'organisation mais la contrepartie de leur puissance c'est leur complexité.
Dans un projet collaboratif le gap est encore plus important que pour un outil centralisé. Et les developpeurs sont tellement sensibilés à la gestion de conf dans les écoles qu'il vaut mieux aller au plus simple.
[^] # Re: bazaar
Posté par Joël SCHAAL . Évalué à 1.
Après tout, on pourrait aussi bien faire un montage "svn" comme on ferait un montage nfs, sauf qu'on rajouterait des commandes permettant de gérer les commit/update/branch...
Ou alors un modèle plus proche de la base de données : utiliser des transactions pour faire des modifications.
Bon je pense que ces aspects ont déjà été étudiés et qu'en terme d'efficacité ils ne sont pas envisageables. (Ce ne sont que des idées, je ne suis pas allé vérifier...)
[^] # Re: bazaar
Posté par Boa Treize (site web personnel) . Évalué à 1.
[caricature]Commence par demander bien bas aux gestionnaire du projet de t'accorder l'immense privilège de pouvoir, avec prudence et respect, apporter une correction infime dans un sous-répertoire (mais pas ailleurs) de leur chef d'oeuvre.[/caricature]
En outre je ne stocke pas l'ensemble du réferentiel sur mon poste.
[caricature]Et quand le serveur crashe, tu perds tout.[/caricature]
Bref, deux avantages du distribué à ce niveau :
- C'est plus égalitaire, pas de verrouillage possible par une quelconque cabbale
- Tout le monde à une copie de l'historique sur son poste (avec des backups en plus, bien sûr)
Par ailleurs, bonne chance pour faire un checkout ou un commit dans le train ou l'avion.
[^] # Re: bazaar
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: bazaar
Posté par golum . Évalué à 5.
Dans le cadre de développement purement communautaire les outils distribués sont plus adaptés. Linux en est le meilleur exemple. Lorsque le développement est conduit en entreprise ou dépend d'une organisation (type Eclipse, Apche, ....) (et non pas d'un homme) le centralisé convient mieux. En entreprise d'autant plus qu'il faut la plupart du temps former les prestataires aux outils de l'entreprise.
[caricature]Commence par demander bien bas à l'intgrateur du projet d'accepter de merger tes modifs mêm mineures dans l'archive de référence[/caricature]
[caricature]Et quand mon dd crashe et que j'ai pas fais de push depui 6 mois je perd tout [/caricature]
D'autant que les solutions de sauvegardes ne sont pas faites pour les chiens , elles s'applique au distribué comme au centralisé
Si l'intégrateur refuse de prendre en compte tes patche le pb est le même et il n'est pas plus difficie de forker un repository que de déclarer que son archive est la nouvelle référence.
Mais personne n'a l'archive de toutes les versions du projet lorsqu'il est très volumineux. Dans ce cas tu es bien obligé de prévoir un serveur pour l'héberger au moins par sécurité et tu te retrouves avec les mêmes contraintes que le centralisé
Ton checkout/commit se fait dans l'archive local ,ca ne signifie pas que tu mettes à disposition du reste du monde.
Dans les 2 cas tu peux toujours travailler en déconnecté et tu mets à disposition quand tu reviens sur le réseau (commit en centralisé et push/pull en distribué).
Le seul avantage est qu tu peux "sauvegarder" des versions intermédiares de ton travail mais le travail de fusion reste entier.Comme avantage c'est bien maigre comparé aux contraintes d'organisation.
Que se passe t'il quand l'intégrateur est overbooké par un afflux de patch. Le projets doit s'organiser en sous-branche afin d'absorber la charge.
Dans le cas d'un modèles centralisé plusieurs intégrateurs peuvent travailler de concert
Encore une fois l'usage dépend du besoin et je ne pense pas qu'on puisse dire que l'un est meilleur que l'autre.
[^] # Re: bazaar
Posté par wilk . Évalué à 4.
On peut également au choix garder le repository dans le dossier du projet (.bzr) ou dans un repository extérieur, local ou distant, avec un système de mise à jour très pratique si on a beaucoup de branches (pour ne pas tout dupliquer) ou en guise de sauvegarde.
Ainsi toutes les combinaisons sont possibles ! Par exemple pour un même projet quelques devs peuvent travailler en centralisé comme cvs/svn pendant que d'autres travaillent sur leurs branches hors ligne.
On omet souvent de dire aussi que c'est très pratique même si on travaille seul où on ne cré pas des branches par développeur mais des branches par clients ou pour ajouter une fonctionalité, corriger un bug etc.
Le seul problème je trouve c'est qu'il y a tant de combinaisons possibles et de modes d'organisation, que ça devient un poil difficile de savoir laquelle sera la meilleure.
# Presque off topic
Posté par spotty . Évalué à 1.
Des commentaires sur Gnu Arch vs autre ? Quelques aspects qui m'intéressent chez Gnu Arch c'est non seulement le branch/merge efficace mais aussi la décentralisation et la signature des changements.
Tout info est bienvenue
[^] # Re: Presque off topic
Posté par golum . Évalué à 4.
http://linuxfr.org/~GomGom/19107.html
[^] # Re: Presque off topic
Posté par Boa Treize (site web personnel) . Évalué à 2.
Une version de GNU Arch est sortie cet été, et Tom Lord est tout à fait présent sur les mailing-lists de GNU Arch, même si ce n'est peut-être plus lui qui maintient le projet.
Par contre, la plupart des utilisateurs semble être partie vers d'autres horizons. (Git, Mercurial, Bazaar, principalement, je suppose.)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.