golum a écrit 2289 commentaires

Comme je sais que les références religieuses sont en "odeur de sainteté" ici, j'aimerais vous citer la Bible en guise de référence ....historique pas morale hein :)

Après la mort de Jésus la communauté des premiers chrétiens avait pour mission de répandre la "bonne parole" à travers le monde. Des congrégations ont donc été etablies dans certaines villes et les apôtres communiquaient avec leurs frères avec des "lettres". Dans une de ces lettres, Paul (faudrait vérifier) écrivit aux corynthiens (à vérifier aussi). Il s'adressa à la confrrie car certains membres envisagaient d'arrêter d'exercer leur métier et de se consacrer pleinement à l'enseignement de la bonne parole tout en ne vivant que des dons .

Remplacez la bonne parole par la Debian, les membres permanents par les release manager, et la confrérie par le rest de la communauté et 2000 ans après les mêmes question se posent.
Bon je vous raconterai pas la fin parce que ca va pas vous plaire.

C'etait ma parabole, Amen :D

Et si ils n'avaient pas mis cette note, ils y en auraient eu certains qui n'auraient pas manqué de dénoncer la partialité des modos.

Quand il faut chier au goût de tout le monde.
M'etonne pas qu'il y ait de moins en moins de dépêches.
Moi qui ne connait absolument rien aux débats, je suis content qu'on me mette en garde.

J'ai tout essayé:

- le bouquin "Arrêter de mouler en 10 séances aux éditions "Du bouchot"
- le patch anti-conchylitinine,
- l'acupuncture avec des arêtes de merlu
- les séances de thérapie de groupes aux cybernautes anonymes

Rien y fait!
Alors si tu as un remède miracle je te refiles tout mon stock d'XPs :)

Tu as raison sauf que free ne m'a pas prevenu avant de brider ma bande passante alors que lorsque 9 augmente ma facture je suis averti et je peux choisir de résiler (sans frais qui plus est). Tout ca pour ne pas faire exploser leur standard en en trompant les gens sur la marchandise.(C'est nous les moins cher , soyez pas crétins)

Le différence c'est donc la transparence

Je confirmes.
J'en suis à ma 3e cure de désintox et j'ai encore rechuté

Je pense simplement que l'usage n'est pas le même.

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é

C'est plus égalitaire, pas de verrouillage possible par une quelconque cabbale

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.

Tout le monde à une copie de l'historique sur son poste (avec des backups en plus, bien sûr)

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é

Par ailleurs, bonne chance pour faire un checkout ou un commit dans le train ou l'avion.

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.

Et puis un jour tu vas arrêter de travailler seul dans ton coin et tu va decider de participer à un projet qui concernent plusieurs developpeurs et là, tu va devoir comprendre comment ca fonctionne:

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.

Merci d'avoir pris la peine de répondre à chacun d'entre nous

Alors, je n'ai pas les détails (je les aurai au SVN Summit),

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(...)

Je pense que ca doit être prévu. Tous les scripts d'admin et les trigger SVN son en pyhton donc ils ont du être confronté au pb.

Bon on va pas rentrer dans les details techniques car il y aurait beaucoup à dire et on risque de digresser pas mal.

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.

Ah et il ne faut pas croire tout ce que te disent les marketeux d'IBM.
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.

Nous n'envisageons pas de migrer les projets existants mais seulement d'utiliser SVN pour des nouveaux projets j2ee.

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.

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.

Vous êtes sur de ça ?

Sur la roadmap:
http://subversion.tigris.org/merge-tracking/

Subversion's own merge tracking support is still in the conception stage. Email the development list if you're interested in participating in its definition or implementation.

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.

Peut-être mais je pense que ca ne devrait être appliqué que pour des anciens nos (genre 6 mois après la parution papier) comme le suggère Ontologia.Sinon j'ai bien peur que les copies ne se répandent et fasse de l'ombre à la version papier.

Le système ca pourrait être un peu comme a l'époque des mags avec ou CDs. Tu achètes le mag avec une option pdf un peu plus chère et tu récupères un ticket avec un id. Tu le saisis sur le site pour qu'il t'envoie le pdf par mail 6 mois après. Comme ca tu gardes ta collec en pdf et tu economises de la place dasn ton armoire en refilant la version papier à ton lug.

Je sais pas si tu as bien lu les derniers liens mais a mon avis les libristes ont de quoi être circonspect.

Note qu'un des premiers émane du Figaro, bien connu pour ses inclinations cryptocommuniste et l'avant dernier de Libé , fer de lance de l'ultralibéralisme :) Coincidence ou influence ?
Quand on dit qu'il faut recouper ses sources.

Tu sais que le phishing ca va chercher loin.

Au moins tu aurais pu faire un lien sur la définition de ces 2 adjectifs car leur sens est assez méconnu sur DLFP :o)

moi aussi parce que je me sens moins seul :(

Je ne sais pas si ca tiens à ton pseudo ou non
mais j'ai 2 fois la ligne

Ce commentaire est-il pertinent ou inutile ?

sur tous tes posts.

Allez! avoue que c'est toi qui a fait tombé le site pour améliorer tes XPs :D

====> []

T'a pas changé toi. T'as toujours un langage aussi "edulcoré".
Merci de nous procurer ces moments de rigolades anthologiques.

Marrant, y a quelque temps le conformisme ambiant aurait vu ton score passer à -10 et aujoud'hui tu es au firmament.

C'est le plus cynique, j'ai lu un article dans lequel Billou exige que les résultats des decouvertes financées par la fondation soient reversés dans le domaine public. On se demande bien pourquoi il n'applique pas ce principe au logiciel ?

C'est le plus cynique, j'ai lu un article dans lequel Billou exige que les résultats des decouvertes financées par la fondation soient reversés dans le domaine public. On se demande bien pourquoi il n'applique pas ce principe au logiciel ?

Juste une petite remarque.

Seriez-vous prêt à vous abonner à une version électronique payante (.pdf par exemple) de GNU/LINUX MAGAZINE ?

Le dernier à avoir tenté l'expérience était feu "Developpeur Référence", le meilleur magazine francophone orienté dev selon moi.
http://web.archive.org/web/20041009164213/www.weblmi.com/dev(...)

Ils n'ont pas tenu longtemps avec ce modèle économique. (22 nos)
Alors pitié on a déjà pas tant de bons mags que ça , ne commettez pas la même erreur. Vous autorisez déjà les auteurs à publier leurs articles, c'est déjà plus que suffisant

dsl mon poulet :) j'avais lu ton post sans relire celui d'avant.

Sorti du contexte j'ai eu l'impression que tu critiquais l'inertie plus que tu ne défendais sa maturité.

hihi.
deja fait (les deux ;-) ).

Et alors t'en penses quoi ?
Tu nous feras bien un petit journal sur le sujet à l'occasion.

J'espère que tu plaisantes là.

L'api a été remaniée pour la version 3 et la version 4.
T'es pas sous KDE toi pour oser dire un truc pareil :)
SWT, il manque plein de widgets tout simplement parce que au départ c'etait uniquemen la lib d'Eclipse et donc ceratins widgets n'etaent pas forcément necessaires (un peu comme à l'époque de GTK avec Gimp)
Pourquoi Swt progresserait entre chaque version et et Qt stagnerait.
Abandonnes un peu tes préjugés et essayes.

Si tu es vraiment interessé , il y a eu une dépêche y'a pas longtemps sur le sujet
http://linuxfr.org/2006/09/01/21276.html