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.
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)
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
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. ...
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/(...) )
Comme un certain nombre de sujets sur les outils de gestions de versions sont abordés de façon récurrente sur DLFP, je propose de rajouter un commentaire de ce type sur chaque dépêche ou journal sur ce sujet afin d'établir une chaîne.
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:
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(...)
Désolé, mais vu l'interêt pour la gestion de conf en général et Clearcase en particulier un admin n'est pas mieux payé. (sauf consultant externe qui est une compétence rare et peu prisée)
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).
Désolé j'ai beau relire cette phrase je trouve toujours qu'elle s'applique parfaitement à des sytèmes centralisé.
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.
ca s'appelle l'audit de fabrication, c'est une information qui est stockée dans le repository.
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, ....)
Ce que tu indiques en parlant de commentaire est plus de l'ordre confort.
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é.
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.
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
Je crois que tu n'as pas compris le fond de ma pensée.
Je critique une certaine démagogie qui consiste à toujours faire des comparaisons avec d'autres modèles en ne retenant que certains aspects qui appuient leur démonstrations et en négligeant d'autres moins flatteurs.
.
Bref, le sport national en ce moment, c'est "comparer les vessies et les lanternes".
parce que je trouves qu'il y a de plus en plus de journaux qui ne parlent pas de logiciels libres
Je comprend encore que ce soit discutable pour les sujets.
C'est pouquoi il faut encourager les particpants à se servir correctement du site.
Notamment :
- souligner les journaux redondants,
- les inviter quelquefois à s'exprimer sur tribune libre http://tribunelibre.org/(...)
- les inviter à poster dans la bonne catégorie:
- les astuce vont dans "Astuces"
- les questions dans les forums.
De même j'ai remarqué que beaucoup choisissent la première catégorie de la liste pour poster des forums sans rapport http://linuxfr.org/forums/41/(...)
Ca n'apportera que plus de lisibilité.
Mais je crois que certains se disent qu'ils obtiendront plus de réponses en postant dans les journaux car l'audience est plus large , ce qui en défintive fait de l'ombre aux autre catégories.
Un cercle vicieux en quelque sorte.
Puisque tu sembles intéressé à faire vivre le site, je t'encourage à faire de même sans sous entendu cette fois.
C'est vrai et je m'en excuse , mais admets que tu as emis pas mal de crtiques sur le site et son fonctionnement et quand on touche à la "communauté" il faut t'attendre à des réactions sur le même ton.
J'ai choisi le sarcasme parce quequefois ca a plus d'impact en terme de pédagogie ;-)
Je ne pense pas que ce soit si simple.
Depuis la 2ème guere l'opinion publique européenne se veut pacifiste et moins coloniale.
La stratégie des US est clairement différente.
Pour eux l'essentiel est de faire main basse sur les dernières reserves coûte que coûte quitte à utiliser la force et la manipulation des médias.
Il suffit de voir ce qui s'est passé en Irak et la campagne de désinformation actuelle sur les sites américains à propos de Chavez et du Venezuela (prochaine victime d'un renversment par la Colombie qui est armée par les US ?).
Bref, eux se renforcent aussi mais la stratégie est différente.
C'est pourquoi je pense qu'il est important aujourd'hui de rompre avec la politique américaine, organiser la coopération internationale pour vaincre cette hégémonie et faire pression sur les US.
En poussant le raisonnement plus loin, il y a 2 vision du monde pour atteindre l'equilibre consommation/ressources, celle (humaniste) où il y a de la place pour tout le monde si on se serre tous la ceinture et celle où seuls les plus forts (les plus riches) survivront.
3ieme chose : le probleme n'est pas uniquement financier, le petrole n'est pas inepuisable, donc il faut clairement diminuer la consommation pour le preserver le plus longtemps possible (et surtout l'utiliser uniquement dans les industries chimiques au lieu de le cramer dans des 4x4 et des gobelets en plastiques a la cafet' au boulot)
Y'a qu'une chose qui me gêne dans ce beau discours.
Nous, en France on doit se serrer la ceinture pour préparer l'avenir, pendant ce temps on puise dans nos résereves stratégiques pour que certains pays puissent continuer à gaspiller avec leur gros 4x4 (si encore cette réserve avit servi à offrir de l'essence au gens qui sont restés sur place en Louisianne parce qu'il pouvaient pas se payer un pleen)
Pour nous baissse de la consommation => recession
Pour eux gaspillage => croissance
et après y'en a qui debarquent et qui viennent nous donner de leçon sur le déclin francais.
Franchement, mon journal de départ était fait pour donner une astuce à ceux qui utilisent Firefox
Tu as découvert dans un autre thread le sytème de notation de DLFP , Bravo, maintenant tu es mûr pour découvrir autre chose.
Regarde au dessus de ta page en haut le 7e menu.
Allez je t'aide http://linuxfr.org/tips/(...)
et tu ne comprend pas ailleurs dans le thread pourquoi Charles Bronson suscite autant d'intêret.Ca fait partie de ces sujets trépidants
comme Pierre Tramo, qui aident à fixer les moules sur le rocher DLFP.
Y'a eu un journal, y'a pas si longtemps qui en parlait et qui les repertoriait.
Tiens ,d'ailleurs n'aurait t'il pas plutôt sa place dans les actuces, section DLFP, lui aussi
Je ne suis pas spécialiste
mais tu as un verbe : violer
qui a 2 subtantifs dérivés:
violation et viol.
La définition que tu cite est celle du verbe
donc on dit une violation des droit et un viol.
(ah, et j'ai plus confiance en wikipédia et ses nombreux contributeurs qu'en gniarf tousseul)
[^] # Re: Bazaar
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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 golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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 golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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: Suivez la chaine
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
http://linuxfr.org/comments/579366,1.html(...)
# Suivez la chaine
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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: Bazaar
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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: A ce sujet...
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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: Après les journaux trollogène ...
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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 ;-)
[^] # Re: A ce sujet...
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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: Après les journaux trollogène ...
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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: Bazaar
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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é.
# Après les journaux trollogène ...
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. É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
# Bourvil
Posté par golum . En réponse au journal 22 ans aujourd'hui. Évalué à 2.
L'alcool non, l'eau ferrugineuse ...
Hips
[^] # Re: "dans les bacs"
Posté par golum . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 2.
Pas étonnant depuis le temps qu'il traîne dans les bacs.
Par où ? ah ok ok ==========> [ ]
[^] # Re: Le selecteur de fichiers gnome
Posté par golum . En réponse à la dépêche GNOME 2.12 dans les bacs. Évalué à 7.
un dico serait vraiment une bonne petite acquisition ;-)
[^] # Re: Tsync
Posté par golum . En réponse au journal synchronisation de fichiers entre plusieurs PC/OS. Évalué à 3.
http://samba.anu.edu.au/rsync/(...)
[^] # Re: mouarf
Posté par golum . En réponse au journal à propos du prix de l'essence. Évalué à 2.
Je critique une certaine démagogie qui consiste à toujours faire des comparaisons avec d'autres modèles en ne retenant que certains aspects qui appuient leur démonstrations et en négligeant d'autres moins flatteurs.
.
Bref, le sport national en ce moment, c'est "comparer les vessies et les lanternes".
Je n'encourage pas au gaspillage.
[^] # Re: owh
Posté par golum . En réponse au journal à propos du prix de l'essence. Évalué à 2.
Bien vu comme quoi la précipitation
[^] # Re: RIP
Posté par golum . En réponse au journal Le saviez-vous ? les bookmarks dynamiques avec Firefox. Évalué à 4.
Je comprend encore que ce soit discutable pour les sujets.
C'est pouquoi il faut encourager les particpants à se servir correctement du site.
Notamment :
- souligner les journaux redondants,
- les inviter quelquefois à s'exprimer sur tribune libre
http://tribunelibre.org/(...)
- les inviter à poster dans la bonne catégorie:
- les astuce vont dans "Astuces"
- les questions dans les forums.
De même j'ai remarqué que beaucoup choisissent la première catégorie de la liste pour poster des forums sans rapport
http://linuxfr.org/forums/41/(...)
Ca n'apportera que plus de lisibilité.
Mais je crois que certains se disent qu'ils obtiendront plus de réponses en postant dans les journaux car l'audience est plus large , ce qui en défintive fait de l'ombre aux autre catégories.
Un cercle vicieux en quelque sorte.
Puisque tu sembles intéressé à faire vivre le site, je t'encourage à faire de même sans sous entendu cette fois.
[^] # Re: RIP
Posté par golum . En réponse au journal Le saviez-vous ? les bookmarks dynamiques avec Firefox. Évalué à 3.
J'ai choisi le sarcasme parce quequefois ca a plus d'impact en terme de pédagogie ;-)
[^] # Re: mouarf
Posté par golum . En réponse au journal à propos du prix de l'essence. Évalué à 3.
Depuis la 2ème guere l'opinion publique européenne se veut pacifiste et moins coloniale.
La stratégie des US est clairement différente.
Pour eux l'essentiel est de faire main basse sur les dernières reserves coûte que coûte quitte à utiliser la force et la manipulation des médias.
Il suffit de voir ce qui s'est passé en Irak et la campagne de désinformation actuelle sur les sites américains à propos de Chavez et du Venezuela (prochaine victime d'un renversment par la Colombie qui est armée par les US ?).
Bref, eux se renforcent aussi mais la stratégie est différente.
C'est pourquoi je pense qu'il est important aujourd'hui de rompre avec la politique américaine, organiser la coopération internationale pour vaincre cette hégémonie et faire pression sur les US.
En poussant le raisonnement plus loin, il y a 2 vision du monde pour atteindre l'equilibre consommation/ressources, celle (humaniste) où il y a de la place pour tout le monde si on se serre tous la ceinture et celle où seuls les plus forts (les plus riches) survivront.
[^] # Re: mouarf
Posté par golum . En réponse au journal à propos du prix de l'essence. Évalué à 6.
Y'a qu'une chose qui me gêne dans ce beau discours.
Nous, en France on doit se serrer la ceinture pour préparer l'avenir, pendant ce temps on puise dans nos résereves stratégiques pour que certains pays puissent continuer à gaspiller avec leur gros 4x4 (si encore cette réserve avit servi à offrir de l'essence au gens qui sont restés sur place en Louisianne parce qu'il pouvaient pas se payer un pleen)
Pour nous baissse de la consommation => recession
Pour eux gaspillage => croissance
et après y'en a qui debarquent et qui viennent nous donner de leçon sur le déclin francais.
Y'a pas comme un pb ?
[^] # Re: owh
Posté par golum . En réponse au journal à propos du prix de l'essence. Évalué à 2.
C'est pas Coluche qui a dit dans un de ses sketches.
"Dites ce dont vous avez besoin, je vous expliquerez comment vous en passer."
Indémodable
[^] # Re: RIP
Posté par golum . En réponse au journal Le saviez-vous ? les bookmarks dynamiques avec Firefox. Évalué à 2.
Tu as découvert dans un autre thread le sytème de notation de DLFP , Bravo, maintenant tu es mûr pour découvrir autre chose.
Regarde au dessus de ta page en haut le 7e menu.
Allez je t'aide
http://linuxfr.org/tips/(...)
et tu ne comprend pas ailleurs dans le thread pourquoi Charles Bronson suscite autant d'intêret.Ca fait partie de ces sujets trépidants
comme Pierre Tramo, qui aident à fixer les moules sur le rocher DLFP.
Y'a eu un journal, y'a pas si longtemps qui en parlait et qui les repertoriait.
Tiens ,d'ailleurs n'aurait t'il pas plutôt sa place dans les actuces, section DLFP, lui aussi
Que la force soit avec toi Jeune "Pas d'avoine"
[^] # Re: Mais quand comprendra-t-on ?
Posté par golum . En réponse au journal Universal Music: a vot' bon coeur.... Évalué à 4.
mais tu as un verbe : violer
qui a 2 subtantifs dérivés:
violation et viol.
La définition que tu cite est celle du verbe
donc on dit une violation des droit et un viol.
(ah, et j'ai plus confiance en wikipédia et ses nombreux contributeurs qu'en gniarf tousseul)