El Titi a écrit 3940 commentaires

Bonne question, je me demandais comment il était si simple de forker un projet lorsqu'on ne détient pas le copyright.

Avec Linux le passage GPLv2 vers v3 est impossible car il faut que tous les auteurs soient d'accord.
Si le projet passe en GPLv3, on retombe dans le même pb, si on refuse une cession de copyright à une unique entité. Tout passage à une autre licence ou version devient compliqué.

Est-ce qu'avec une LGPL on fait ce qu'on veut ? (A priori c'est l'intérêt de cette licence)

Un spécialiste es licences pour corriger ?

Je crois que l'idée est de faire des petits utilitaires simples et de les proposer à qui veut bien.

Parcher rsync ca nécessite de se mettre au C, de s'impliquer dans un projet qui n'a pas la même vocation (par ex le renommage de fichiers pour éviter l'écrasement n'est pas trivial en utilisant un outil de synchro)
Sinon, faire un backend à un programme qui ne propose pas d'API n'est pas forcément du goût de tout le monde (pas du mien en tout cas)
http://www.mail-archive.com/rsync@lists.samba.org/msg18288.h(...)

Est-ce que tu as moyen de détecter simplement que 2 partitions ne sont pas sur le même disque ?
Parce que sinon ton optimisation ne marche pas toujours.

Ultracopier ayant eu son heure de gloire sur DLFP:
http://linuxfr.org//2010/01/24/26384.html

ca parait être une bonne idée.

Et pour vous mâcher le travail

j'ai «profité» de la perte de ma boîte de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je
...
Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
Et je finis avec un petit lien vers mes autres projets en cours:
-lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et ...

Un journal soigné et du bon boulot en tout cas.

Ca serait pas mal de créer une catégorie "coup de coeur" pour les petits projets qui se lancent.

https://bugzilla.redhat.com">notre système de suivi d'anomalies.

avec comme url
https://linuxfr.org/submit/%3Ca%20href=



et mêmes les plus ancienne

même est un adverbe ici
http://francite.net/education/cyberprof/page111.html



les bindings Python développés par Nokia sous licence LGPL. L'environnement GNUStep est également introduit.

Autres temps, autres moeurs.

Dans une autre vie, les lapsus te servaient visiblement d'argumentaire:
http://linuxfr.org/comments/822108.html#822108
http://linuxfr.org/~euroxers/23509.html

En même temps elle est excusable, l'inflation aussi fait gonfler ... les prix.

http://www.agoravox.fr/culture-loisirs/dessin-du-jour/articl(...)

Oui, quand est-ce qu'on pourra utiliser librement les données qui ont été collectées grâce à nos impôts ?

C'est balo, hein ?
Non, mais c'est ballot
http://fr.wiktionary.org/wiki/c%E2%80%99est_ballot

Simplement parce que le branching avec SVN est bloated. Une usine à gaz a été créé pour pallier les défauts d'architecture que j'ai exposé un peu plus loin.
Cette belle idée au départ de pouvoir brancher à plat directement dans l'arborescence couplée avec cette notion de révisions qui simule des "liens symboliques" et qui pointe que sur les fichiers modifiés depuis la dernière révision était séduisante. (branche et tags en O(n)). L'équipe SVN s'était dit qu'ils s'occuperaient des branches plus tard (mémoire de merge, rename tracking, pas de merge cycliques, ... par exemple) et dans les faits c'est tout qui est à revoir. (pour le rename tracking il faut des identifiants d'objet alors qu'on a que des révsions ou un DAG+notion de branche pour être efficace). Leur modèle se complique (mergeinfo qu'il faut supprimer à la main, révisions à indiquer explicitement parce la mémoire de merge est défaillante, option reintegrate pour traiter les branches de patch, ...) Ils sont dans une impasse ... Ca explique pourquoi on trouve ca dans la section advanced.

http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)

Du coup on conseille de bosser dans une branche et on promeut l'intégration continue puisqu'on ne sait traiter que ça.

Désolé, j'ai rien compris à ce que tu voulais expliquer.

L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.


Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.

SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.

Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.

La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).

Pour en remettre une couche sur le rename tracking voici une description
du problème:
http://subversion.tigris.org/issues/show_bug.cgi?id=898

Etant donné que SVN utilise svn cp pour brancher et ne fait sémantiquement pas la différence entre une branche et une simple copie d'arbo ce problème n'est pas près d'être résolu. Les branches sont des objets à part entières dans Git

Quelque commentaires:



"""
Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
renames branch, it won't be merged before 1.3.
...
Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
move to 1.8-consider.
...
Seems like this thing is going to be pushed out indefinitely.
"""


Ce bug a été ouvert en 2002 et il est reporté aux calendes grecques.
Nous en sommes à la 1.6.12.
Bonne chance les gars

Je ne suis pas sûr de bien comprendre, mais connais-tu les changelists ?
http://svnbook.red-bean.com/en/1.5/svn.advanced.changelists.(...)

Ceci permet de regrouper les changements à commiter.
Le mécanisme n'est pas aussi puissant que la mise en place de branches dédiées (inhérent aux DVCS) qui permet de commiter les changements de manière unitaire puis de reporter ceux que l'on souhaite sur le tronc (cherry-picking). D'ailleurs, si quelqu'un a déjà pu utiliser le cherry-picking correctement avec SVN, je suis preneur pour un retour d'expérience.

J'ai l'impression que votre différence d'appréciation provient de votre perspective.
Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.

Je m'explique:
Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.

Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.

Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.

En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.

Ce workflow est plus complexe mais plus souple.
C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.

Voilà je crains avoir encore plus délayé que toi.

Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc.

Ce n'est pas le rôle du VCS mais du bugtracker ou de la forge de faciliter cette communication.
S'il est centralisé, on sait qui a pris quoi, à quoi est dédiée telle branche.

J'entends souvent l'objection que tu évoques à savoir ce risque d'isolation qui fait que SVN colle si bien à l'intégration continue i.e à l'usage d'un branche unique.

Et pourtant la CI n'est pas l'apanage des outils centralisés.
Je te conseille cet excellent papier de Martin Fowler sur le sujet
http://martinfowler.com/bliki/FeatureBranch.html

En revanche, ce qui est sûr c'est qu'un outil comme SVN qui est incapable de supporter le "rename tracking" correctement (renommer un fichier différemment entre 2 branches perd l'historique de ce fichier lors du prochain merge entre ces 2 branches) ne peut supporter que l'integration continue et les branching par patch (une branche par patch que l'on tue une foi integrée).
Pas de salut pour les autres branching patterns (1 branche par developpeur , une par lot de fonctionnalité en vue d'un développement parallèle de plusieurs équipes avec une phase d'intégration avant la livraison, ...)

De là à dire que la mode de la CI n'existe que parce que SVN est déficient à la base, il n'y a qu'un pas.

http://www.google.fr/search?q=point+permis+a+vendre

Il semblerait qu'ils jouent à fond le jeu de l'open source car ils ont publié leur style de rendu et on peut voir un peu partout des références et liens vers OSM.


Où peut-on récupérer les sources de leur outil de calcul d'itinéraire ?

Savez-vous s'il existe de tels services en ligne libres au dessus d'OSM ?

Aucun doute, ils sont partis pour atteindre des sommets.

Ca va faire plaisir aux e-commercants ce que tu dis.

Il avait surtout fait une honteuse contrefaçon de la svastika.
http://fr.wikipedia.org/wiki/Croix_gamm%C3%A9e

depuis que "The Art of Noise" existe.

Quelle est la différence si tu prêtes ta voiture et que tu reçois un PV. Tu es considéré comme responsable tant que tu ne dénonces pas le coupable.

Si tu te l'ai fait piquée tu dois le déclarer.
Si t'es parti en vacances et que tu n'étais pas au courant tu devras prouver tes dires.
Avec HADOPI c'est le même principe sauf qu'il est très difficile de savoir quand ta voiture a été piquée à l'insu de ton plein gré. Mais si tu as installé OpenOffice sur une machine qui ne fait rien, tu as prouvé ta bonne foi.
Que demander de plus ?
Qu'est-ce qu'on va rire !

Oui c'est le mal de notre société, hein !

Aujourd'hui, si tu ne sécurises pas ta piscine et qu'un cambrioleur se noie dedans, tu risques des ennuis.