L'implémentation originale, tla, vient d'être abandonnée par son auteur. Le fork, Bazaar, est en passe d'être remplacé par Bazaar 2, alias Bazaar-NG, alias bzr, plus simple et plus rapide. GNU Arch a commencé par un ensemble de scripts shell, nommé larch et développé par Tomas Lord. Plus tard, Tom a réécrit ces scripts en C, ce qui a donné l'implémentation tla (comme Tom Lord Arch).
Plusieurs développeurs ont alors rejoint le projet, et donné lieu à de nombreuses améliorations. Malheureusement, Tom a été de plus en plus lent à intégrer les contributions à la branche officielle, et en a même refusé un certain nombre explicitement (par exemple, un système de cache a été proposé pour éviter de télécharger plusieurs fois la même chose, la réponse de Tom a été « I see no reason to modify arch in the slightest little bit to solve *that* problem. »). Les contributeurs ont commencé à publier leur branche d'intégration de manière non-officielle pour que des utilisateurs puissent bénéficier des améliorations avant qu'elles ne soient intégrées officiellement à tla.
Pendant ce temps, Canonical (NdM : la société de Mark Shuttlewoth, plus connue pour la création d'Ubuntu) a décidé d'utiliser GNU Arch comme gestionnaire de version, et a commencé à investir pour faire évoluer l'outil. Plusieurs développeurs de GNU Arch ont alors été embauché par Canonical, une proposition avait même été faite à Tom, qui l'a refusée. Voyant que les améliorations sponsorisées par Canonical avaient peu de chances d'être intégrées à tla, Canonical crée une branche, nommée Bazaar. Pendant un temps, elle sert de branche de développement pour tla, alors que Tom travaille sur des projets qui n'aboutiront jamais (un nouveau langage : XL, une première tentative de réécriture de tla, ...). Un jour, il décrète que le code source de Bazaar n'est pas de qualité suffisante, il remercie le mainteneur, et jette tout le travail qui avait été fait sur une release candidate de la version 1.4, pour travailler sur une version 1.3.1.
Pendant ce temps, Bazaar évolue et s'améliore, au niveau performances et interface utilisateur. En février 2005, Canonical lance un autre projet, Bazaar-NG. À l'origine, c'est un prototype, un terrain d'expérimentation pour valider des concepts qui doivent ensuite être implémenté dans Bazaar lui-même. Il est maintenu par Martin Pool, auteur de rsync, distcc et ccache, et écrit en Python.
Bazaar-NG évolue vite, et même s'il est encore jeune (il utilise encore un format de stockage très inefficace, mais un format plus compact est prévu pour la prochaine version), Canonical décide en Juillet dernier que Bazaar-NG 1.0 sera Bazaar 2. La version 1.x de Bazaar n'évoluera plus après la version 1.5, dont la sortie est imminente, sauf pour des corrections de bugs. Canonical devrait commencer sa migration vers Bazaar-NG en octobre.
Entre temps, Tom Lord a annoncé qu'il abandonnait tous ses projets de logiciel libres, y compris tla, et recv qui était une seconde tentative de réécriture de GNU Arch inspirée de git.
En conclusion, tla et plus tard Bazaar 1.x ont joué un rôle important dans l'histoire des gestionnaires de versions répartis. Aujourd'hui, ils laissent place à Bazaar 2, qui devrait tirer parti de l'expérience de GNU Arch tout en apportant de grosses améliorations. À noter qu'entre temps, plusieurs alternatives viables sont apparues. Par exemple, Mercurial, Monotone et GIT.
Aller plus loin
- GNU Arch (7 clics)
- Bazaar (7 clics)
- Le site d'origine de Bazaar-NG (5 clics)
- Un journal sur l'abandon de GNU Arch par Tom Lord (6 clics)
- Mercurial (4 clics)
- Monotone (1 clic)
# Bazaar
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
N'est'il pas possible de regrouper les forces, d'écrire un cahier des charges (comme au temps du début de subversion) et de programmer ensuite un truc solide et pérenne ?
[^] # Re: Bazaar
Posté par Olivier Grisel (site web personnel) . Évalué à 8.
BZr est vraiment un super système : simple et intuitif à utiliser, plus réactif qu'un subversion (car travail en local : pas de connexion réseau pour un commit), un code très testé (tests unittaires et doctests), un système de plugins pour pouvoir personnaliser et améliorer facilement et la volonté de faire du code portable (windows est supporté) pour toucher le plus grand nombre. De plus la communauté est très active avec une boîte qui embauche des devs à plein temps pour bosser sur le projet ...
En plus le code est en python, bien documenté et il est donc facile d'y contribuer ce qui rend ce projet particulièrement sain. Le jeu de tests permet d'organiserer régulièrement des refactoring de composant sans tout casser.
Comme tla et bazaar ferment boutiques progressivement, leurs communautés respectives se tournent vers bazaaz-ng ce qui en fait un candidat très probable pour être l'équivalent décentralisé de subversion.
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par Zakath (site web personnel) . Évalué à 2.
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par Zakath (site web personnel) . Évalué à 3.
Et toutes les modifications et adjonctions qu'on lui fait maintenant sont de plus en plus difficiles parce qu'elles n'ont pas été prévues dès le départ.
Il n'y aurait pas sieur Torvalds qui pèse de tout son poids (fort subséquent par ailleurs), personne ne l'utiliserait.
Franchement, arrêtez d'utiliser git et passez à des vrais scm conçus par des gens qui savent ce qu'ils font, comme mercurial ou monotone.
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par or zax . Évalué à 1.
J'avais aussi fait des tests mais sur les opérations de commits sur l'arborescence du noyau, c'était très raisonnable.
GIT est surtout le fruit de la méthode de travail des développeurs du noyau.
C'est comme ceux qui voulait persuader Linus d'utiliser svn alors qu'il avait clairement dit qu'il voulait du décentralisé.
Le problème n'est pas technique, en terme de fiabilité, de rapidité ou de fonctionnalité.
Chaque outils induit une façon de travailler. A partir du moment ou aucun produit ne correspond à la méthode de travail, un nouveau est créé.
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par Boa Treize (site web personnel) . Évalué à 1.
Du vrai troll à l'ancienne comme on n'en fait plus assez, des affirmations fausses mais crédibles balancées avec aplomb, des attaques ad hominem, la mention de programmes concurrents... Tout y est, tout marche, la preuve le commentaire est à +6.
Zakath, je te tire mon chapeau ! (Et regrette de ne pouvoir dépertinenter ton commentaire qu'une seule fois.)
[^] # Re: Bazaar
Posté par Zakath (site web personnel) . Évalué à 1.
Les attaques ne sont pas ad hominem (même si Linus Torvalds est effectivement un con), simplement git et Torvalds sont indissociables puisque le second est le créateur et indéfectible supporter du premier, et que les choses ont l'air bien parties pour qu'il en fasse une question d'amour-propre, comme avec BitKeeper.
Et d'ailleurs, je ne vois pas non plus en quoi le fait de dire que monotone et mercurial sont meilleurs que git fait de mon post un troll.
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Facile, tu argumentes pas, tu ne donnes aucunes explications. Tu condamnes juste.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par Antoine . Évalué à 2.
http://www.selenic.com/hg/?cmd=file;filenode=b0166ba7a8977756db92a8(...)
[^] # Re: Bazaar
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Attention, git permet maintenant aussi d'avoir un repository delta-compressé, donc du même ordre de grandeur de taille que celui de mercurial.
[^] # Re: Bazaar
Posté par mickabouille . Évalué à 6.
[^] # Re: Bazaar
Posté par Philippe F (site web personnel) . Évalué à 6.
Quelques points notables:
- git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
- git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.
- git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.
Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
- versionnement des fichiers
- remonter dans le temps sur les versions passees
- notion de branche
- notion de marquage (tag)
Apres, on peut rajouter d'autres fonctionnalites :
- commit atomiques
- renommage
- utilisation en mode completement decentralise facon arch
- interface conviviale
- compacite du stockage
- facilite de deploiement
- portabilite
- nombre d'outils et frontend associes
- stabilite
- dispoinbilite d'un frontend sous windows
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.
Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.
Pour Linus, c'est git.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Ça n'est plus entièrement vrai :
http://git.or.cz/(...)
Two, interchangeable, on-disk formats are used:
* An efficient, packed format that saves space and network bandwidth.
* An unpacked format, optimized for fast writes and incremental work.
En fait, par défaut, il utilise la version "intégrale", et de temps en temps, on peut faire convertir explicitement dans l'autre format. Du coup, les dernières révisions (celles dont tu as vraiment besoin) sont accessibles rapidement, et les vieilles ne gaspillent pas l'espace disque, tout en restant accessibles.
Pour info, il y a des gens qui sont en train de migrer de GNU Arch à git, et qui en sont contents (cf. les recentes discussions sur gnu-arch-users).
[^] # Re: Bazaar
Posté par Boa Treize (site web personnel) . Évalué à 2.
Grossière erreur de logique.
Ceci dit, par ailleurs, git n'a jamais prétendu être pour tout le monde. Il ne prétend pas non plus être pour Linus et/ou Linux uniquement.
git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte.
C'est faux. Git stocke une version compressée des fichier (compression zlib maximum).
CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
C'est faux. Git peut stocker les objets sous forme compactée, et dans ce cas il est assez efficace en termes de stockage et encore tout à fait performant. Par exemple, Linux 2.6.11 avec son historique prend 191 Mo sous forme classique (chaque fichier étant compressé) et 62 Mo sous forme compactée. À comparer avec les 250 Mo des sources décompressées.
- versionnement des fichiers
Que veux-tu dire précisément ? Bien sûr que Git permet de retrouver les anciennes versions d'un fichier, même si techniquement ce n'est pas immédiat. Je ne sais pas si une commande existe déjà, mais conceptuellement je vois bien comment le faire : il faut remonter la hiérarchie des commits (donnée par git-rev-list), voir dans chaque arbre associé au commit si le fichier de même nom a la même signature SHA1. Si ce n'est pas le cas, tu as trouvé une ancienne version du fichier.
- remonter dans le temps sur les versions passees
Un petit coup de git-checkout permet de récupérer ultra-rapidement l'arborescence des fichiers telle qu'elle était à n'importe quel commit donné.
- notion de branche
Bien sûr. Git, comme tu le reconnais toi-même, c'est le royaume de la branche.
- notion de marquage (tag)
Bien sûr. En fait, n'importe quel objet peut être tagué. En général ce sont des commits qui sont tagués (pour marquer une version, typiquement), mais un arbre ou un fichier peuvent également l'être.
- commit atomiques
Je crois bien. De toute façon, vu que chacun bosse dans sa copie locale...
- renommage
Un point faible de Git, je pense. Pas facile de suivre à rebours l'évolution d'un fichier qui a changé de nom et de contenu. Trivial par contre de suivre l'évolution d'un fichier qui a changé de nom mais pas de contenu (merci SHA1).
- utilisation en mode completement decentralise facon arch
Bien sûr. C'est un des points forts de Git.
- interface conviviale
Le coeur de Git n'est pas convivial, et n'a pas à l'être. C'est de la plomberie. Pour la porcelaine, j'ai pas encore trop testé, mais gitk (explorateur de l'historique d'un projet) déchire grave, et git-web (même genre version html) déchire grave aussi. Cf. http://www.kernel.org/git/(...)
- compacite du stockage
Déjà traité, Git n'a pas à rougir.
- facilite de deploiement
Git est très simple et très léger, et ne requiert rien de bien méchant.
- portabilite
Git ne fonctionne effectivement pas (encore ?) sous Windows. Dommage. Il marche sous beaucoup d'Unix, y compris les versions récentes de Mac OS X.
- nombre d'outils et frontend associes
Ça évolue très vite. Cf. http://git.or.cz/(...)
- stabilite
Le projet n'a pas encore six mois, c'est clair qu'il bouge encore beaucoup. Mais qu'attendre d'autre au bout de seulement six mois ?
- dispoinbilite d'un frontend sous windows
Ah ben non, pas encore.
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS
Aucun des programmes que tu cites ne répondent à tous tes critères. Donc, égalité avec Git ! :-) Par ailleurs, tu as oublié le critère de performance. Git déchire grave et vite à ce niveau, plus que ceux que tu cites je pense.
[^] # Re: Bazaar
Posté par Philippe F (site web personnel) . Évalué à 2.
Il y a des gens qui se disent que si le kernel utilise un truc, c'est forcement le meilleur truc au monde. C'est a moderer fortement, les hackers du kernel n'etant pas des etres humains normaux, mais des hackers du kernel.
> Aucun des programmes que tu cites ne répondent à tous tes critères.
Ce sont des criteres en vrac. De fait, mon argumentation est justement qu'il n 'y a pas de SCM universel pour l'instant.
Dans ma boite mes deux commerciaux utilisent CVS quotidiennement sous windows grace a tortoise CVS. Ca ne serait possible ni avec arch, ni avec git, ni avec tla. Subversion serait envisageable. Malgre tous les inconvenients de CVS, c'est de loin une des meilleurs solutions par rapport a mon besoin.
J'ai oublie d'ailleurs dans mes criteres la facilite d'utilisation. CVS, un utilisateur utilise quotidiennement deux commandes : commit update. Rien qu'en voyant la page de man de git, je laisse tomber. Il va me falloir deux heures pour comprendre de quelles commandes j'ai besoin et lesquelles ne me servent a rien.
Et puis niveau stabilite, si la porcelaine evolue, ca ne convient peut-etre pas a tout le monde.
J'ai regarde le mode pack mais j'ai pas trouve de description de l'operation de packing qui est faite derriere. Je ne peux donc pas dire si c'est efficace ou pas comme methode de stockage.
[^] # Re: Bazaar
Posté par Victor STINNER (site web personnel) . Évalué à 8.
Peut-être pour avoir un changelog plus précis que "hou là là, je sais plus !" ? :-) Ça m'est déjà arrivé ça, genre commit 2 semaines après et diff bcp trop long, aïe.
Haypo
[^] # Re: Bazaar
Posté par LeMarsu . Évalué à 9.
Avec subversion ou CVS, tu codes, tu codes, et tu commit un très très gros diff une fois que tu as récupéré le net. Les commentaires du diff seront douteux, et peu précis.
Avec arch, svk ou autre décentralisé, tu commit en local sans te soucier de l'accès au net. Quand tu as fini tes grosses modifs (a raison de plusieurs commit), tu mets à jour le serveur distant pour que tout le monde en profite.
Perso, j'apprécie beaucoup, dans mes voyages Lyon-Paris, 2h sans le net, ça veux pas dire 2h sans pouvoir commit...
LeMarsu, qui espère avoir été clair.
[^] # Re: Bazaar
Posté par Anonyme . Évalué à 3.
Je me rappelle avoir lu un message de Tom Lord qui déclarait que dans peu de temps, il n'existerait plus de serveur CVS et autres du genre, parce que tout se ferait en décentralisé.
Il a apparemment raccroché le tablier avant d'avoir supplanté CVS... Ca ressemble un peu à une fable de Lafontaine qui parle d'ours...
« Avec arch, svk ou autre décentralisé, tu commit en local sans te soucier de l'accès au net. Quand tu as fini tes grosses modifs (a raison de plusieurs commit), tu mets à jour le serveur distant pour que tout le monde en profite. »
Mais est-ce que ça marche à ce point si bien que ça pour gérer les conflits ? Parce qu'a priori, si deux humains modifient les mêmes bout de code, la machine doit quand même avoir du mal à deviner quoi garder...
Et si une solution miracle a été trouvée à ce sujet, à vrai dire, que ce soit décentralisé ou pas ne devrait rien y changer.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
1) Y'a encore des gens qui ont une connection pas permanente. C'est sympa de faire plusieurs commit et de publier le tout en une fois au moment ou tu te connecte.
2) Les pannes de réseau, ça arrive. Commiter en local, ça veut aussi dire être capable de commiter quand le serveur est planté.
3) Qu'évoquent pour toi les mots "ordinateur portable" par rapport à la connection au net ;-) ?
> Mais est-ce que ça marche à ce point si bien que ça pour gérer les conflits ?
Un gestionnaire de versions, quel qu'il soit, ne remplace pas une bonne organisation. Ca t'aide, c'est tout. Si deux personnes modifient le même bout de code, il y a conflit, point. Un intéret d'un gestionnaire de version par rapport au merge à la main, c'est qu'il te dit là ou sont les conflits, c'est déjà ça.
Avec un système centralisé, le conflit apparait au moment de l'update, avant le commit. Si l'update bousille ce que tu avais fait, c'est la galère (en général, tu as l'original des fichiers ou il y a conflit dans un coin, mais ça ne suffit pas forcément. Par exemple, tu peux avoir un update sans conflit mais qui ne compile même pas). Avec une branche par développeur, quand tu es content de toi, tu commit, et après, tu fais un merge. Si le merge casse tout, tu peux faire la différence entre ce qui vient de toi et ce qui vient du merge, c'est déjà ça.
[^] # Re: Bazaar
Posté par Anonyme . Évalué à 4.
Disons que théoriquement, si tu dois avoir des conflits, c'est entre des branches (je parle de CVS là). Les commits fait sur un arbre principal ne devraient jamais crée de conflit si le projet est bien organisé.
En gros, chacun fait sa branche à la maison, avec arch, si je comprend bien. Certes, il peut être interessant d'avoir une branche sans l'accès au net. Toutefois, il est aussi vachement commode d'avoir une branche sur un tronc commun, de manière à suivre le développement (en particulier si le merge n'est pas géré par l'auteur de la branche).
Hormis les défauts habituels de CVS (dossiers ineffaçables, etc.), concrètement, en terme de gestion de projet, l'aspect révolutionnaire de la chose est assez discret. Finalement, il ressort surtout l'intérêt du *non connecté* avec le défaut du *chacun fait sa branche chez soi* (même si c'est à la mode de vouloir tout décentraliser, la centraliser permet dans un bon nombre de cas d'homogéneiser, de controler et de mieux superviser). A vrai dire, n'étant pas concerné par le *non connecté* (je ne suis pas un ultra-geek : la où il n'y a pas internet, c'est lorsqu'il est bon de faire autre chose que de tripatouiller un ordi... lire un bouquin par exemple... je ne suis pas du genre).
Interessant, mais pas révolutionnaire :)
[^] # Re: Bazaar
Posté par or zax . Évalué à 1.
Ce côté distribué te permet d'isoler de façon centralisé ou pas, certains efforts de développement.
Exemple tu utilises une librairie version 1.5, le temps passe un la version 3 sort. Une fonctionnalité ou une correction de bug t'intéresse.
avec la façon de travailler des outils distribués, cette ajout fait dans la version 3, sera dans une branch dédiée souvent.
Toi tu ne vas pas tout migrer de la version 1.5 à 3 car trop de coût de migration.
et bien avec un système distribué.
Une ligne de commande unique et tu fais un backport tout seul. par exemple.
Et ce n'est qu'un exemple. Ces outils n'ont pas vocation à révolutionner. par contre ils apportent beaucoup de souplesse.
Pour ce qui est des conflits, ça ce gère très bien. les fonctions de merge étant très importantes pour des systèmes distribués, les merges sont particulièrements soignés et bien écris, parfois plus que dans pas mal de systèmes centralisés, donc les conflits apparaissent pas aussi facilement que l'on pourrait le penser.
Autre point le coût de mise en place d'une infrastructure centralisé et distribué, il faut mettre des serveurs spécifique en place en centralisé, en distribué non donc gain en terme de coût (ps : le temps est aussi un coût, je ne parle pas forcément en terme monétaire).
Bref le distribué c'est quelque chose de plutôt sympa, maintenant cela ne remplacera pas le parc actuel des systèmes centralisés, car le but est de proposer une plus grande diversité dans la façon de travailler, pas de tout casser. Des personnes ont écris des outils qu'ils auraient aimé avoir avant c'est tout.
[^] # Re: Bazaar
Posté par Anonyme . Évalué à 3.
Ce côté distribué te permet d'isoler de façon centralisé ou pas, certains efforts de développement.
Exemple tu utilises une librairie version 1.5, le temps passe un la version 3 sort. Une fonctionnalité ou une correction de bug t'intéresse. »
« Distribué », c'est un nouveau terme pour que « décentralisé » paraisse toujours être une idée avant-gardiste.
Parce que ce dont tu parles peut sans problème avec un système centralisé. Avec CVS, par exemple. Les tags et les branches, ça ne sert qu'à ça.
Par contre, je demande à voir l'aspect réaliste de ton exemple : si ta bibliothèque s'incrémente de deux versions majeures, il est fort probable que ta fonctionnalité qui t'interesse repose des éléments n'existant pas dans le code que tu as toi.
[^] # Re: Bazaar
Posté par or zax . Évalué à 1.
Si j'insiste sur le terme distribué, c'est uniquement par rapport au fait que dans ces systèmes là, tu créé des branches à tout va car c'est simple à faire, ça ne coûte rien en terme de stockage et ça te permet des merges avec une granularité plus fine.
Par rapport à mon exemple c'est simple, plus l'écart de version est important, plus ton risque d'avoir des conflits est important. C'est le bon sens
PAr contre si la fonctionnalité en plus repose sur d'autres fonctionnalités (avec d'autres branches etc ...) ça augmente la profondeur du merge c'est tout. Donc pas de problème. si la fonctionnalité est très simple et ne repose que sur peu de changement entre les deux versions, à ce moment tu ne fais pas un merge mais tu appliques juste le patch nécessaire.
Sinon par rapport "« Distribué », c'est un nouveau terme "
un nouveau terme de quelque decenni, la notion d'informatique distribué c'est presque aussi vieux que l'informatique elle même
"pour que « décentralisé » paraisse toujours être une idée avant-gardiste."
Qui a dit que le distribué c'est avant gardiste, personne, la différence c'est que c'est une façon de travailler qui n'était pas courante dans RCS, maintenant les solutions existentes ont plus de variété.
Monotone, Mercurial, Arch, Darcs etc ... ne font pas une révolution,ils facilitent certaines tâches c'est tout.
La seule différence entre aujourd'hui et il y a quelques années, c'est que les gens utilisait CVS car c'était pratiquement le seul choix possible (sourceforge etc ...), maintenant il y a plus de choix, et ce qui resterons sur CVS, resterons dessus parce que ça répond à leur besoin, et non par obligation. A la rigueur cà c'est un énorme changement, et ça n'a rien avoir avec distribué ou pas, limite subversion a plus de mérite à ce niveau là.
Donc tel produit tel caractéristique et tel produit tel autre ça avance à rien. Tel produit induit tel type d'utilisation ou l'autre produit aura sa logique d'utilisation, tu choisis celui que tu trouves le plus agréable. Si tu t'éclates avec CVS ou Subversion ou n'importe quel produit, personne ne te demande de changer.
Maintenant, si tu veux comprendre l'engouement de certaines personnes pour bazaar par exemple, teste le, et là tu verras que l'utilisation n'est pas du tout pareil, après ça te plait ou pas ça ne regarde que toi. Maintenant Bazaar, Monotone, et compagnie ne font absolument rien de plus que CVS, car comme CVS ce sont des RCS et rien d'autre.
[^] # Re: Bazaar
Posté par golum . Évalué à 5.
Avec d'un système réparti où chacun dispose d'une archive en local et donc de la possibilité d'historiser plusieurs changements, c'est au niveau de la "gestion" des changements que tu as une plus value.
Un projet informatique se decompose en général en une suite d'implémentation de certaines exigences ou demandes de changement identifiées (change request).
Chacune d'entre elle se doit d'être historiser afin de la tracer et eventuellemenent de la repercuter sur d'autres branche (maintenance, ...)
Avec un tel système tu peux prendre en charge plusieurs demandes alors qu'avec un système centralisé tu historises tous les changement en une seule fois au moment du retour sur le réseau sans différencier le code qui a permis de réaliser chaque changement.
Après pour gérer les demandes de changements tu peux te contenter d'utilsre les commentaires ou t'integrer avec un outil de tracking.
L'autre avantage est la possibilité de forker (par exemple parce que l'auteur d'un projet te refuse l'accès en ecriture) puis de réintegrer par la suite les modifications suivant les humeurs.
D'ailleurs si on regarde l'historique de Arch et Bazaar on voit que cette souplesse facilite (encourage?) ce genre de pratique à bon ou mauvais escient.
Vous avez dit Cathédrale ou Bazaar ?
Le mythe revisité.
[^] # Re: Bazaar
Posté par Olivier Grisel (site web personnel) . Évalué à 5.
Rien n'empeche de mettre un rsync dans un cron ou dans un post-commit hook pour mettre à disposition ses modifs sur un serveur http public au fur et a mesure de ses developpement quand un acces reseaux est dispo.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression. Avec Bazaar, ça m'arrive très souvent de commiter un truc que je sais être cassé, pour le réparer dans les commits suivants. Dans la branche principale, il n'y a pas de regression par contre.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. Avec un gestionnaire de versions décentralisé, chacun a les droits sur son archive, et c'est tout. On peut travailler à plusieurs dans de bonnes conditions sans donner des droits à qui que ce soit (du moment que chacun a un bout d'espace web).
Pour aller plus loin, la gestion de version distribuée est un très bon moyen de favoriser la revue de code, et de garder une branche stable vraiment stable. C'est le point clé qui permet le développement de Linux comme on le connait depuis la version 2.6: Une nouvelle fonctionnalité est développée séparément, testée dans différentes branches, soumises à sa majestée Torvalds, qui en général t'enverra bouler « ton patch, il est pas bien, faut changer ça, ça, ça et ça ». Les demandes d'améliorations sont faites sur la branche dédiée à la fonctionalité en question, qui est maintenue un phase avec la branche principale. Un jour, le code est estimé comme étant de qualité suffisante et est intégré à la branche principale.
La gestion de version répartie, quand tu y as touché, tu as du mal à revenir à une gestion centralisée.
[^] # Re: Bazaar
Posté par MetalX . Évalué à 3.
La gestion centralisée multibranche peut quand même être intéressante. Dans ma boîte, seuls les serveurs sont backupés quotidiennement, donc la meilleure façon de travailler est à mon sens d'avoir une branche par développeur. Cela revient un peu à ce que tu mentionnes dans ton premier point, mais je reconnais que c'est un cas particulier.
En plus, comme tu le mentionnes, la gestion des droits est probablement plus simple.
[^] # Re: Bazaar
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 5.
Je vois bien l'intérêt de pouvoir disposer d'un espace local sur lequel faire des commit lors des phases de dev. sans accès au réseau. Pour SVN (et CVS) il y a la notion de mirroir offerte par SVK.
Coté multi-branche, SVN propose aussi ce mécanisme. Dans la doc officielle, il est même recommandé d'allouer des bracnhes aux développeurs lorsque la modification est un peu importante et peut nécessiter plusieurs commit avant stabilisation.
Par contre, je crois qu'il n'est pas facile (bien que certainement faisable) de distinguer les droits d'un utilisateur "standard" et d'un responsable de branche (branche principale mais aussi branche de stabilisation/correction).
Il me semble que la différence entre chacune des solutions réside surtout dans la taille du projet. Quelqu'un a des infos à ce sujet (genre "à partir de 20 dev. il vaut mieux bzr") ?
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Ensuite, sur la gestion des branches, c'est une grosse faiblesse de SVN : Il ne garde pas l'historique des merge, donc, quand tu fais un merge, c'est a toi de dire quelle version utiliser comme ancetre commun.
Avec une gestion avancée des branches, tu dit "merge", et il se débrouille pour appliquer chaque patch une et une seule fois.
Il faut voir aussi que la gestion centralisée est aussi possible avec des outils comme Bazaar. Le décentralisé est en général un surensemble du centralisé.
[^] # Re: Bazaar
Posté par golum . Évalué à 2.
On en a déjà parlé là
http://linuxfr.org/comments/573573.html#573573(...)
et là
http://linuxfr.org/comments/579101.html#579101(...)
Sinon si la souplesse est un avantage du modèle décentralisé celui ci a aussi ses inconvénients.
Pas facile de savoir où en est l'avancement des demandes de bug requests si chacun prend en charge 40 bugs dans son coin et commit sa branche une fois tous les 6 mois.
De même pas facile de mettre en place un accès à une resource avec un jeton de reservation et ce afin de se prémunir du modification concurrentes. C'est uitle pour certains type de fichier qui ne supporte pas de gestionnare de merge (image, fichiers au format propriétaire, ....)
http://linuxfr.org/comments/579260.html#579260(...)
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
> chacun prend en charge 40 bugs dans son coin et commit sa branche une fois
> tous les 6 mois.
C'est clair. Je dis et je répète : un gestionnaire de version ne remplace pas une bonne organisation. Pour les bugs, je trouve qu'il est très important que la gestion des bugs soit centralisée. Idealement, le bugtracker doit garder trace de la personne responsable, de la branche dans laquelle c'est corrigé, et de la révision dans laquelle c'est intégré à la branche principale.
Pour la gestion des bugs, le meilleur exemple de ce qu'il ne faut pas faire, c'est l'historique du développement de GNU Arch ;-) (des bugs ont été rapportés dans 3 systèmes différents mais n'ont jamais été corrigés).
[^] # Re: Bazaar
Posté par golum . Évalué à 2.
Tu peux préciser ce point. Toujours en mettant à part le fait d'historiser des changements intermédiaires, en quoi est-ce différent d'un système centralisé ?
Tu fais un checkout du repository,
tu fais des modifs,
tu updates de temps à autre
et après soit tu commit parce que tu as obtenu les droits sur le repository soit tu envoies un patch.
Avec un sytème décentralisé le pb est le même si tu n'as pas de droit en ecriture sur l'archive principale ?
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression.
Rien n'empêche de créer une branche par développeur et au moins le chef de projet voit où en est l'état d'avancement des changements que tu prends en charge.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
En disposant d'une copie de travail rien ne t'empêche de travailer en mode déconnecté, la seule limitation étant encore et toujours de ne pas pouvoir historiser de changements intermédiaires.(et encore c'est une feature qui devrait pouvoir être implémneté par clonage de working copy).
Les seuls outils que je connaisse qui souffrent de limitation sur ce point car les copies de travail sont connectée en permanence avec le serveur sont Clearcase avec les vues dynamiques (et pas snapshot), Vesta( http://www.vestasys.org/(...) ) et Aegis ( http://aegis.sourceforge.net/(...) )
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
Autre exemple:
- Bonjour, voici ma contribution (cf. patch joint)
- J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
- Ben, euhhh
Encore un:
- Les gars, j'ai commencé à bosser sur la fonctionalité X, vous pouvez tester ma branche située ici: http://www.../(...)
- Pas mal. Moi, j'aurais bien mis Z à la place de T.
- OK, je fais ça. Voilà, c'est commité.
- Ah, ouais, c'est mieux. Tu peux changer U par V dans toto.c ?
- Je m'en occupe et je publie ça.
En un autre pour la forme:
- Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)
- Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
- OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
Mais, bon, tu peux argumenter que tu ferais tout ça avec un éditeur de texte et "cp -r". En effet, tu peux faire à la main ce que des outils te permettent de faire facilement de manière automatisée, y'a pas de scoop là.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Si tu envoies un deuxième patch qui est un surensemble du premier, et que le premier a déjà été appliqué, y'a conflit à coup sur.
[^] # Re: Bazaar
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 4.
C'est bizare. De mémoire, le vénérable CVS savait déjà détecter qu'un patch/merge a été fait. Il détecte que les lignes sont IDENTIQUES et ne râle pas. Maintenant, dans des cas complexes (genre beaucoup beaucoup de modifs très proches), aïe aïe aïe.
[^] # Re: Bazaar
Posté par golum . Évalué à 2.
Si ta branche est déclarée (une branche pour tous les contributeurs non décalarés par exemeple), le fait de disposer d'une mémoire de merge ne dépend pas du modèle centralisé ou non.
SVN l'intègrera en 1.4, Clearcase en dispose depuis l'origine (fl^che hyperlien de merge) et MetaCVS comble cette lacune de CVS (http://users.footprints.net/~kaz/mcvs.html)(...)
Mais encore une fois dans le contexte opensource je conviens que le modèle décentralisé présente un intêret, pour intégrer des modifs d'un contributeur non déclaré.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Non, je ne confonds pas. Avec un modèle décentralisé, tu peux faire une branche chez toi sans rien demander à personne. Avec le modèle centralisé et les solutions que tu propose, tu n'as PAS de solution pour faire un merge, donc tu es obligé d'envoyer un patch.
> le fait de disposer d'une mémoire de merge ne dépend pas du modèle centralisé ou non.
Non, mais tu fais comment pour avoir une mémoire des branches que tu as fusionnées depuis une archive qui n'est pas l'archive principale avec un modèle centralisé ? (c'est justement ça la grosse différence entre les deux modèles)
[^] # Re: Bazaar
Posté par golum . Évalué à 3.
Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
Et pourtant mon "système" (1 branche par développeur + 1 pour l'intégration) a déjà été largement adopté dans le monde de l'industrie.
Ca s'appelle UCM (Unified Change Management). Il s'agit d'une surcouche à Clearcase qui s'inscrit dans la démarche RUP d'IBM Rational.
La branche (stream) d'intégration répertorie les baselines stables de la release courante du projet.
Chaque developpeur prend en charge une ou plusieurs demandes de changements et les réalise dans sa branche propre. Lorsqu'il souhaite récupérer les dernières avancées stables (baseline) il effectue un "rebase" qui est en fait un merge amélioré de la branche d'intégration vers sa propre branche.
Lorsqu'il a completé un certain nombre de changements, il les "delivre", c'est à dire qu'il effectue ou demande qu'on effectue un merge de sa branche vers celle d'intégration en ne prenant en compte que les changeset correspondant au demandes qu'il souhaite livrer.
S'il souhaite développer une nouvelle fonctionnalité dans sa branche à partir d'un changement qui est n'est pas encore integré dans la branche principale rien ne l'en empêche.
Le fait que la branche du developpeur soit sur un serveur distant ou en local n'affecte en rien le modèle.Il est de toute façon possible de deporter une branche sur un autre site avec Clearcase (Multisite).Ceci est d'ailleurs dynamique (transfert des droits d'ecriture sur la branche ) et différe des modèles décentralisé type Arch. (je peux developper si ca t'interesse)
Autre exemple:
- Bonjour, voici ma contribution (cf. patch joint)
- J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
- Ben, euhhh
Ici tu soulignes le fait de travailler en mode pull.
En décentralisé type Arch, un membre autorisé de l'archive centrale peut faire un pull de la branche du contributeur sans le déclarer puis merger la branche rapatriée sur la principale. En mode gestion centralisée, le contributeur doit être déclaré et travailler sur une autre branche du serveur ou une branche déportée.
Je conviens que cette facilité corresponde mieux au dev Open Source type Linux. En entreprise, l'intêret est beaucoup moindre puisque tout contributeur est connu et qu'on doit tracer les changements qui lui sont affectés .
De même en entreprise il est plus fréquent que ce soit le contributeur qui fasse le merge d'integration car c'est lui qui a la meilleur connaissance de ce qu'il touche. L'équipe d'intégration se contente de passer les tests d'integration, d'accepter ou de refuser de promouvoir la baseline.
En un autre pour la forme:
- Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)(...)
- Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
- OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...)(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
Rien n'empêche de faire la même chose en centralisé, du moment que le dev à les prérogatives pour créer un sous-branche.Cette technique s'appelle "branchement par activité". Elle permet entre autre de corriger un bug urgent en repartant d'une baseline antérieure alors que des fonctionnalités moins urgentes ont déjà eté développées.
Désolé pour la réponse fleuve mais tu as abordé un peu tous les sujets.
[^] # Re: Bazaar
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
-1- Un client Windows super (TortoiseSVN) stable et complétement intégré à l'explorateur de fichier. C'est vraiment facile à utiliser. J'ai amené pas mal de personne à utiliser un système de versionnement grace à ce client.
-2- Une gestion transparente des fichiers binaires. C'était un des défauts majeur de CVS.
Plus évidement pas mal d'autres défaut de CVS comme le fait de ne plus faire d'import sauf à l'initialisation du projet.
Il est vrai que le fait de ne pouvoir commiter dans le train est vraiment génant pour les développeurs. C'est idiot que svn ne le propose pas car il a déjà un cache de tous les fichiers du serveur en local dans ses dossiers .svn (afin notament de pouvoir faire des diff sans contact avec le serveur central). Il devrait donc être possible de faire des commits différés.
[^] # Re: Bazaar
Posté par Antoine . Évalué à 2.
Tu peux utiliser svk qui est un front-end amélioré à SVN, et permet de créer un repository local en mode miroir (tu committes en local, et tu synchronises de temps en temps avec le repository distant). J'ai testé brièvement et ça marche bien. En plus ça suit l'historique des merges (svk smerge).
http://svk.elixus.org/(...)
[^] # Re: Bazaar
Posté par golum . Évalué à 2.
Sauf que tu est obligé de faire des pull /push avec l'archive distante après ton commit en local pour diffuser ton travail donc tu as bien des connexions réseau.
Tu remplaces le cycle
checkout-edit-update-merge-commit
par
checkout-edit-pull-merge-commit-push.
Je ne vois pas en quoi c'est plus simple ni plus efficace en terme de réseau.
En plus le code est en python, bien documenté et il est donc facile d'y contribuer ce qui rend ce projet particulièrement sain. Le jeu de tests permet d'organiserer régulièrement des refactoring de composant sans tout casser.
Oulah Attention si Timaniac rôde dans les parages, tu vas déclencher un mag-troll sur la fiabilté des langages fortement typé vs typage dynamique
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Par ailleur, tu n'es pas obligé de te connecter à chaque commit. Comme le mec qui fait "check mail" avant de partir en voyage, qui réponds à ses mails dans le train, et qui envoie le tout en batch quand il retrouve sa connection au net.
> checkout-edit-pull-merge-commit-push.
Surtout pas. Un des gros intérêts du système décentralisé, c'est justement de ne pas mélanger un pull et une édition à la main.
# Arch est le premier, mais pas le seul
Posté par LeMarsu . Évalué à 6.
Mais bon, tla possède 150 commandes différentes, avec des noms de 15 caractères en moyennes, c'est pas facile à utiliser... Pour faire son premier import, il y avait au moins 3 ou 4 commandes différentes. Mais comme il savait faire le star-merge, je restais dessus.
Un jour un ami m'a montré subversion. Je trouvais ça pas mal, et tellement rapide (par rapport à arch). C'était bien, mais il n'y avait pas moyen de faire un star-merge. Pour commit dans le train, alors que le serveur est distant, c'était pas très pratique. Donc, je n'ai pas migré, même si je m'en servait pour certains projets.
Un jour, j'ai découvert svk ( http://svk.elixus.org/(...) ça n'a pas l'air de répondre à l'heure ou j'écris mon commentaire). En gros svk, c'est une surcouche de subversion, écrite en perl. Mais, il est aussi décentralisé que peut l'être arch! Et ça, c'était la killer-feature que j'attendais :) Son plus grand défaut doit être son installation (environ 20 modules perl...).
Je ne connais pas Bazaar, et ne me permeterais pas de juger le projet. Mais, bon, depuis que j'ai découvert svk, je suis pas prêt d'en changer.
LeMarsu, avec ces 2 centimes.
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien (site web personnel) . Évalué à 4.
[^] # Re: Arch est le premier, mais pas le seul
Posté par Misc (site web personnel) . Évalué à 2.
voir le début ( à l'heure ou j'écrit ces lignes ) de doc sur :
http://qa.mandriva.com/twiki/bin/view/Main/ForkingCvsWithSvk(...)
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien (site web personnel) . Évalué à 1.
Je crois que je tenais cette idée du wiki SVK, qui n'est peut-être plus à jour :
http://svk.elixus.org/?SVKCVS(...)
PS. je me suis mis à SVK avec l'article de Scott Laird:
http://scottstuff.net/blog/articles/2005/07/07/distributed-developm(...)
http://typo.cdlm.fasmz.org/articles/2005/07/15/distributed-version-(...)
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien (site web personnel) . Évalué à 1.
urf, en effet, it does o_O
bon OK, rubyforge est ptet pas d'un répondant exemplaire non plus :-)
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien (site web personnel) . Évalué à 1.
et il me fait des «Can't decode commit message as utf8.» de temps en temps aussi.
[^] # Re: Arch est le premier, mais pas le seul
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Pour la complexité de tla, Bazaar a quand même pas mal amélioré la situation. Pour un import par exemple, il n'y a plus que deux commandes (init-tree + import), et le message d'erreur si tu essaye de faire un import sans le init-tree, ou un commit à la place du import te dit quelle commande tu aurais du utiliser. Mais ça reste un gestionnaire de version assez complexe, c'est clair.
Bazaar-NG par contre est franchement simple à utiliser. Il y a un système de plugins qui permettra de garder les trucs compliqués à l'écard des débutants (je vois ça un peu comme les extensions firefox). Par ailleurs, les développeurs sont des gens très compétents, je leur fait confiance pour nous faire un système excellent.
# Tailor
Posté par Antoine . Évalué à 6.
http://www.darcs.net/DarcsWiki/Tailor(...)
# Tant qu'on y est...
Posté par denjer . Évalué à 1.
Avec darcs, on n'est pas obligé d'avoir de repository fixe (chaque répertoire de travail contient un ensemble de patches, que l'on peut transbahuter à loisir), c'est vraiment agréable. OK, j'ai pas testé bazaar-ng, peut-être il peut le faire aussi.
- d
[^] # Re: Tant qu'on y est...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Bazaar-NG adopte aussi le système "répertoire de travail = repository". Il faut quand même faire attention à une chose : dans ce système, une création de branche se fait par copie intégrale du repository, qui est une opération chère. Je ne sais pas comment Darcs gère ça. Avec Bazaar-NG, on peut faire une copie avec liens en dur sur les systèmes qui le supportent, c'est une première optimisation. Des gens travaillent sur un stoquage centralisé qui permettra de faire une branche rapidement, et sans gaspiller d'espace disque.
[^] # Re: Tant qu'on y est...
Posté par Antoine . Évalué à 3.
C'est ce que font déjà Monotone et svk, à ma connaissance.
# A ce sujet...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 3.
En fait, je me pose la question car, chez nous, nous utilisons deux types de base de gestion de conf.
La première sert à l'équipe de développement pour... développer. On a donc toto et gugus qui font des commit réguliers (de l'ordre de la journée ou demi-semaine).
La seconde sert au service de gestion en conf. pour suivre tout ce qui est livré au client. Celle-ci sert beaucoup plus rarement (genre deux trois~fois sur un projet).
Là où le bas blaisse, c'est que par manque de recul on utilise les mêmes outils. Pourtant les besoins sont radicalement différents (AMHA). Dans le premier cas, il me semble malgrès l'article mais vu la taille de nos équipes et notre organisation (peu d'itinérant), que SVN est une bonne solution. Dans le second cas, je sèche.
Que conseiller ?
[^] # Re: A ce sujet...
Posté par ham . Évalué à 2.
Ce que je ne trouve pas c'est la gestion de configuration aussi détaillé[1] que le couple clearmake/clearcase, donc si un pro de darts, bazaar*,... etc sait si il y a des frontend, toussa ou des manière de faire la même chose, je suis a l'écoute
[1]: la feature que j'aime bien c'est que quand clearmake fabrique un objet dérivé (résultat d'une action du makefile), il note les versions des fichiers utilisé, et la commande pour le faire.
Si le collégue a produit un binaire, je peut savoir comment il l'a produit *exactement*, jusqu'a la versin des .h de la libc.
J'aime bien ca parceque cela ne demanque aucun effort en plus.
Je pense qu'en ayant des attributs sur les fichiers, ou les objets dérivé stocké de manière particuliere dans le gestionnaire de version, c'est possible, mais j'aimerais savoir si ca a été déja implémenté..
[^] # Re: A ce sujet...
Posté par golum . Évalué à 5.
Le problème c'est que dès que tu sors de ta vue (working copy) et que tu livres ton binaire, tu n'as plus cette trace.
Donc 2 solutions soit tu fais bien gaffe as toujours labelliser ce que tu livres soit tu utilise le technique de timestamping (marquage des executables) pour enregistrer toute l'arbre des dépendance dans ton binaires.
Autre avantage de clearmake. Clearmake est utilisé avec des vues dynamiques qui s'appuient sur un fs maison. Du coup toutes les accès à un fichier sont tracés? Donc quand tu compiles un .c qui fait apple à un include, clearmake detecte que le compilo ouvres le .h et ajoutes automatiquement dont une dépendance.
Du coup tu n'as plus besoin d'indiquer explicitement la dépendance dans ton makefile.
Autre avantage le partage d'objet dérivé. un binaire qui a déjà été compilé autre part dans le même contexte (même dépendance, mêm environnement) n'est pas regénéré mais directement recopié (lien symbolique) dans ton espace de travail (gain de temps et d'espace).
Tu as aussi, la compilation des cibles en parallèle.
Les inconvénients:
Clearmake n'est utilsable qu'avec les vues dynamiques qui sont connectées en permanence avec le serveur donc uitlsable qu'en LAN ou WAN musclé.
Avec les vues dynamiques tous les commits apparaissent instantanément (pas d'update) du coup ton environnemnt est suceptible d'être perturbé sans que tu le demandes (pb de correspondances des sources en debug, compil impossible, ....)
[^] # Re: A ce sujet...
Posté par Philippe F (site web personnel) . Évalué à 2.
Dit autrement:
- avec subversion/CVS, tu peux avoir un admin a temps partiel
- avec ClearCase, il te faut deux admin a temps plein
[^] # Re: A ce sujet...
Posté par golum . Évalué à 3.
Pour le temps passé ca dépend de l'organisation. Avec toutes les possibilités de cet outil il faut bien baliser le sentier et appliquer la même gestion de conf sur tous les projets d'une même boite pour eviter de tout réinventer à chaque fois. C'est sans doute pour ca que ca cible en général des DSI de grande boites (processus qualité toussa).
Et c'est rien comparé au coût des licences.
[^] # Re: A ce sujet...
Posté par MetalX . Évalué à 3.
# Discussion intérressante
Posté par Guillaume Chevallereau . Évalué à 3.
http://mail.gnome.org/archives/gnome-hackers/2005-May/msg00001.html(...)
# Jeu de mot
Posté par Romain Liévin (site web personnel) . Évalué à -2.
En clair, c le bazar dans les noms !
Je sais, c'était facile. Et hop => -1 !
# Après les journaux trollogène ...
Posté par golum . Évalué à 4.
Contrairement à un gestionnaire de versions centralisé comme CVS, il est très facile de créer une branche, et de fusionner depuis une archive distante (« branch and merge » pour les anglophiles).
Comparer les récents Bazaar et Arch à l'antédiluvien CVS pour le branching et le merge et citer ca comme un avantage des systèmes décentralisés.
svn copy
http://svnbook.red-bean.com/en/1.0/re07.html(...)
svn merge
http://svnbook.red-bean.com/en/1.0/re16.html(...)
Clearcase est aussi un sytème centralisé et gère tout ca parfaitement.
Le différence qu'on retrouve dans les sytèmes décentralisés c'est des opération suppléméntaires (push, pull entre archives) qui apporte plus de souplesse pour forker mais aussi plus de complexité.
Bref un peu de neutralité dasn les news serait bienvenue
[^] # Re: Après les journaux trollogène ...
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Bref, si tu lisait le texte que tu critiques ;-).
[^] # Re: Après les journaux trollogène ...
Posté par golum . Évalué à 2.
Copy a file or directory in a working copy or in the repository.
le repository est l'archive distante (il n'ya en au qu'une dans un système centralisé)
et après le copy tu peux extraire une working copy de ta copie, donc tu travailles bien sur une nouvelle branche.
[^] # Re: Après les journaux trollogène ...
Posté par Matthieu Moy (site web personnel) . Évalué à 0.
Par ailleurs, des branches, y'en a même en CVS, hein ...
[^] # Re: Après les journaux trollogène ...
Posté par golum . Évalué à -1.
Tu indiques maintenat plusieurs repositories distants. Un système centralisé n'en à qu'un.Donc la différence n'est pas au niveau du branch and merge mais dans le fait que chaqcun dipsose d'un serveur sur sa machine.
Pour la prochaine news tu pourras mettre que ça permet d'historiser plusiers changement à la suite sans accès au serveur comme c'est déjà développé dans les threadd plus haut.
Sans rancune ;-)
# Suivez la chaine
Posté par golum . Évalué à 2.
On clique sur le lien puis
sur "Lire le journal" pour le consulter en entier
ou sur le lien pointé pour consulter le précédent:
http://linuxfr.org/comments/579366.html#579366(...)
et un thread orphelin
http://linuxfr.org/comments/573380.html#573380(...)
[^] # Re: Suivez la chaine
Posté par golum . Évalué à 2.
http://linuxfr.org/comments/579366,1.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.