Merci

Summer of Code

• [^]Re: Summer of Code

  Posté par David Anderson (page perso, ) le 04/01/2006 à 23:13. (lien). Évalué à 10.

  Oui, je sais que je ne suis pas le seul, et j'espère que mon commentaire ne donnait pas l'impression que je me la pétais genre "Je suis le seul warrior qui a survécu!" Ce n'était pas du tout mon attention.
  
  Je voulais par là répondre à une inquiétude assez répandue du temps du Summer of Code : que la grosse carotte financière n'attirerait que des mercenaires, et n'apporterait au final pas grand chose de durable au libre (c'était souvent suivi par un laïus sur pourquoi il aurait fallu ouvrir le SoC aux non-étudiants aussi, ce que je trouvais d'assez mauvaise foi pour être franc).
  
  Bref, voila. Et sinon, Looking Glass, ca avance? :-)

  • [^]Re: Summer of Code

    Posté par David Anderson (page perso, ) le 04/01/2006 à 23:14. (lien). Évalué à 0.

    Euh, mon intention même. Oups.

  • [^]Re: Summer of Code

    Posté par Pinaraf (Jabber id, ) le 05/01/2006 à 23:14. (lien). Évalué à 7.

    Oui ça avance, bientôt les modifs mineures nécessaires à X.org pour qu'il puisse lancer Looking Glass devraient être acceptées. Pour l'instant on a besoin d'utiliser un serveur X.org patché fourni par Looking Glass, donc ça veut dire qu'après on pourrait avoir Looking Glass au même titre que KDE ou gnome dans kdm/gdm alors que c'est actuellement un peu chiant...
    
    Pour ma part, j'aurais jamais pu autant participer à LG3D sans le SoC, donc forcément je pense pas qu'on puisse dire que c'était du mercenariat :)

Bravo mais...

• [^]Re: Bravo mais...

  Posté par √λιi () le 05/01/2006 à 08:50. (lien). Évalué à 6.

  Etant donné que cela va contre les principes de svn, c'est assez normal. Personnellement, je suis contre l'implémentation de cette "fonctionalité", qui sera :
  - d'une : tellement difficile à implémenter qu'elle sera forcément bancale
  - de deux : trop tentante pour aller faire des modifs que l'on pourrra regretter un jour.
  
  Je suis d'accord que cela pourrait être intéressant. Mais je pense que gloablement, il vaut mieux perdre un peu d'espace disque plutôt que de casser un des principes élémentaires du truc. Par contre, limiter la taille (par configuration) des fichiers binaires pourrait être une idée pour éviter les erreurs ...

  • [^]Re: Bravo mais...

    Posté par gael75 () le 05/01/2006 à 09:40. (lien). Évalué à 5.

    Même si les arguments du "ca casse la principe" sont légitimes, dans la pratique j'ai vraiment perdu du temps en dump/import dans les cas suivants :
    - ajout malheureux de binaires trop gros (SDK), qui fait péter mon backup remote
    - ajout par erreur d'un fichier 'sensible' (un doc)
    
    Après je pense que le dernier cas peut être assez rare pour devoir passer par un dump (même si c'est vite long) et effectivement un hook script doit permettre de limiter l'import des bin.
    
    Sinon en regardant les commentaires sur les implémentations possibles, un obliterate qui laisse le fichier mais avec un contenu vide serait vraiment bancale d'après toi ?
    
    Un dernier point où l'obliterate me rendrait un grand service : nos sources sont souvent accompagnés de fichiers data (des models) qui évoluent dans le temps et prennent rapidement trop de place, or certains son complètement obsolètes (version de test, debug).
    D'ailleurs mieux qu'un obliterate ce serait un paramètre du style "on ne stock de ce fichier que les N dernières versions"
    
    Reste que cela fait plus d'un an que nous sommes passés de cvs à svn, et je ne le regrette pas une seconde (peut être au début les maudits problèmes de droits avec la BDB ;) )

    • [^]Re: Bravo mais...

      Posté par David Anderson (page perso, ) le 05/01/2006 à 13:42. (lien). Évalué à 10.

      En réponse à la question de gael75 sur obliterate, j'ai fait un peu de recherche pour me mettre à jour sur "oùsque ca en est".
      
      Déjà, un peu de fond sur le problème: Subversion a été conçu avec comme principe premier la protection des données à tout prix. Cela se répercute directement dans l'API, et en particulier dans celle qui implémente le "Système de fichiers versionné", le coeur de Subversion.
      
      En effet, si on consulte cette API, on se rend compte qu'elle ne permet pas du tout d'ouvrir et altérer des données qui ont déjà été commitées. Le seul moyen d'éditer un fichier, c'est démarrer un nouveau commit avant d'éditer, auquel cas toutes les modifications se font dans la transaction en préparation, qui est le seul endroit dans Subversion ou les données sont altérables. Donc, au niveau de toute la conception de Subversion, tout ce qui a été committé un jour est par définition immutable.
      
      Ce qui pose un problème très épineux pour obliterate. Là, on nous demande de programmer une commande qui viole quasiment tous les principes de conception de subversion : Il faut altérer des révisions passées (censées être immutables), voire même modifier toute une ligne d'historique pour faire disparaitre un fichier et l'ensemble de ses modifications. Non-seulement nous sommes réticents à le faire sur le principe (c'est mal de donner aux gens de quoi se tirer une balle dans le pied), mais en plus nous serons obligés de contourner notre API pour le faire, parce qu'elle refusera catégoriquement de toucher à ce qui est immutable.
      
      Ensuite, en ce qui concerne la solution que tu proposes (remplacer le fichier par un fichier vide), elle a été réfléchie, en effet. Mais l'inquiétude réside dans le fait que nous avons deux volontés différentes pour la fonction de cette commande : certains veulent simplement une commande "anti-disque-plein", qui serait adéquatement implémentée par le remplacement par le vide. Mais d'autres (et la très légère majorité je crois) veulent que l'effacement soit "juridiquement correct", c'est à dire qu'il n'y aie aucune trace de l'existence même du fichier. Dans ce cas là, il y a besoin de faire un effacement, un vrai.
      
      Il y a aussi des volontés différentes par rapport à ce que obliterate devrait effectivement détruire : une révision? Un fichier et toute son histoire? Une seule révision d'un certain fichier? Le consensus semble être d'implémenter la suppression d'une révision précise d'un fichier précis, puisque toute autre opération peut se construire par dessus. Mais cela pose d'autres problèmes: s'il y a un historique après la révision, il faudrait re-deltifier le dépot, pour conserver son intégrité. Faut-il re-deltifier en effaçant l'existence du morceau supprimé (cas effacement juridique), ou re-deltifier en fusionnant le morceau effacé avec des révisions futures (Le cas "effacement pour gagner de l'espace disque) ?
      
      Problème épineux donc, au niveau de sa conception de haut niveau (que doit effectivement faire 'svnadmin obliterate' ?), au niveau de l'acceptation (pas mal de développeurs ne sont pas favorables au principe ministère-de-la-Vérité d'obliterate. Cela n'empêchera pas son développement, mais réduit le nombre de développeurs prêts à bosser dessus). Mais de loin le plus gros problème que nous aurons à résoudre, c'est qu'en l'état actuel, notre API ne nous permet matériellement pas d'implémenter obliterate, et que nous ne voulons pas rendre disponible dans l'API publique un svn_fs_obliterate() aux conséquences on ne peut plus irréversibles.
      
      Bref, nous n'avons pas oublié la doléance : c'est le bug #516 de Subversion, un vétéran, et il nous concerne toujours. Mais nous travaillons sur des choses plus importantes à nos yeux (récemment, et en vue de svn 1.4 : un nouveau système de stockage de deltas, avec un gain d'espace disque coté serveur avoisinant les 20%, et de nombreuses optimisations de la vitesse de traitement dans la bibliothèque de gestion de copie de travail), et n'avons simplement actuellement pas de temps alloué à ce problème.
      
      Bien sur, si quelqu'un est motivé, les contributeurs sont les bienvenus! ;-)

      • [+] [^]Re: Bravo mais...

        Posté par renoo () le 06/01/2006 à 15:52. (lien). Évalué à -2.

        "Le consensus semble être d'implémenter la suppression d'une révision précise d'un fichier précis, puisque toute autre opération peut se construire par dessus."
        
        Est ce qu'il n'y a pas une solution intermédiaire qui serait la suppression de la dernière revision.. en général c'est surtout du à une erreur de frappe/manip et si ca permet d'éviter de trainer ca dans la base.. ca fait moins ministère de la vérité (que la suppression d'une revision précise d'une version précise) et moins marquage indélébile (que l'absence d'obliterate).

• [^]Re: Bravo mais...

  Posté par snt () le 05/01/2006 à 10:39. (lien). Évalué à 10.

  Pour ceux qui comme moi ne sont pas les rois de la langue de Shakespeare, je signale juste que "obliterate" est un sacré faux ami qui signifie "supprimer definitivement".
  Ainsi un "cvs obliterate" n'a pas comme conséquence d'ajouter une quelquonque etiquette comme mon instinct défaillant tentait de me le faire croire mais plutot d'effacer un truc sans passer par la case corbeille.

  • [^]Re: Bravo mais...

    Posté par etham (page perso, ) le 05/01/2006 à 15:45. (lien). Évalué à 10.

    Ce n'est pas franchement un faux-ami, car en français, au sens premier, oblitérer veux dire effacer.
    
    On connaît surtout l'expression "oblitérer un timbre", mais il semble que cela viennent de l'oblitération des monnaies, qui signifie l'effacement de leur motifs, et c'est bien l'idée d'effacer le timbre de la circulation.
    
    Ma source : dictionnaire de l'académie française, via lexilogos.com

• [^]Re: Bravo mais...

  Posté par lcld () le 05/01/2006 à 12:41. (lien). Évalué à 3.

  Un workaround partiel :
  
  * Utiliser un dépôt de type fsfs
  
  * (optionnel) A la mise en place de ce workaround, exécuter la commande cp db/current .db_current depuis le dépôt.
  
  * Ajouter la commande suivante dans le "hook" post-commit :
  cat "$REPOS/db/current" >> "$REPOS/.db_current"
  
  * Et utiliser le script suivant pour annuler le dernier commit :
  .../bin$ cat svnrevert
  #! /bin/sh
  [ $# != 1 ] && {
  echo 'Usage: svnrevert REPOS_PATH' >&2
  exit 1
  }
  cd "$1"
  set -- `cat db/current`
  [ $# == 3 ] &&
  sed -i '${ g; w db/current
  d}; h' .db_current &&
  rm db/rev{,prop}s/$1
  cd -

  • [^]Re: Bravo mais...

    Posté par David Anderson (page perso, ) le 05/01/2006 à 13:45. (lien). Évalué à 4.

    Cela fonctionne effectivement dans le cas d'un dépot FSFS, mais tu notes que cela ne permet de défaire que la toute dernière révision. Si entretemps la moindre petite chose à été committée, il faut redeltifier tout ce qui suit la révision supprimée, ce qui n'est pas possible dans l'API actuelle de Subversion (cf mon commentaire au dessus).
    
    Donc oui, un workaround partiel, mais cela ne résout pas tous les problèmes qu'obliterate est censé résoudre.

Guide de l'utilisateur en français

• [^]Re: Guide de l'utilisateur en français

  Posté par Jérôme FIX (page perso, ) le 05/01/2006 à 09:30. (lien). Évalué à 5.

  Je ne connais pas de document librement téléchargeable en français, mais il y le bouquin suivant : http://www.oreilly.fr/catalogue/2841772691.html
  
  Sinon en anglais et en ligne :
  http://svnbook.red-bean.com/
  http://subversion.tigris.org/faq.html

• [^]Re: Guide de l'utilisateur en français

  Posté par David Anderson (page perso, ) le 05/01/2006 à 13:58. (lien). Évalué à 2.

  Il y a eu quelques articles de ci de là sur l'utilisation "de base" de Subversion, mais il n'existe à l'heure actuelle aucune documentation en francais traduite.
  
  Le Subversion Book (http://www.svnbook.org/ ), édité en papier par O'Reilly, a été mis en ligne par les auteurs sous une licence Creative Commons libre. Il serait donc possible qu'une équipe de gens motivés en fasse la traduction. Ca s'est déjà fait dans d'autres langues, il faut juste que des gens motivés le fassent :-).
  
  Ah, et des contributions à la l10n française de Subversion sont les bienvenues aussi. Il y a une équipe qui bosse dessus, mais les coups de main sont toujours les bienvenus!

Felicitations a ttes l'équipe !

• [^]Re: Felicitations a ttes l'équipe !

  Posté par Frédéric COIFFIER () le 05/01/2006 à 10:30. (lien). Évalué à 4.

  Pour ton deuxième point, as-tu déjà essayé Unison ?
  
  http://www.cis.upenn.edu/~bcpierce/unison/

  • [^]Re: Felicitations a ttes l'équipe !

    Posté par xeuzuex () le 05/01/2006 à 11:02. (lien). Évalué à 3.

    Non je n'ai pas essayer effectivement.
    
    Mais svn apporte quand meme le confort de gerer en conf. et donc de ne pas se faire de soucis puisqu'on peut tjrs revenir en arriere :-))
    
    Alors qu'avec un outils de synchro il faut certainement etre plus attentif

    • [^]Re: Felicitations a ttes l'équipe !

      Posté par golum () le 05/01/2006 à 13:45. (lien). Évalué à 4.

      Oui en même temps j'ai pas trop envie de versionner toutes les versions .pdf de la doc utilsateur de tous les softs que j'utilise et de tous mes ebooks.
      
      Avec des fichiers binaires pas d'algorithme delta pour le stockage, bonjour la place perdue.
      
      L'idéal serait de choisir pour chaque fichier si on veut le gérer en version ou simplement le partager. J'ai pas creusé unisson mais il a l'air assez interéssant et vu les réferences qu'ils citent, ils ont du pas mal creuser la question.
      http://www.cis.upenn.edu/%7Ebcpierce/papers/index.shtml#File(...)
      
      /me => à essayer d'urgence.

      • [^]Re: Felicitations a ttes l'équipe !

        Posté par David Anderson (page perso, ) le 05/01/2006 à 14:02. (lien). Évalué à 3.

        Subversion implémente xdelta, un algorithme de diff binaire très efficace. C'est l'une des grosses différences par rapport à CVS : Ce dernier stocke le "fulltext" (fichier complet) de toute révision d'un fichier binaire, alors que Subversion fait aussi des diffs dessus.
        
        Bon après, si le binaire en question est un .zip (par exemple), c'est sur que la modif d'une ligne d'un fichier dans le zip produit un delta ridiculement gros, mais ca c'est un problème du à la nature du fichier, et on y peut pas grand chose (sauf pour gzip, ou nous proposons l'intégration générale d'un patch disponible dans debian, qui permet de produire des .gz "rsyncable", tentant de minimiser les changements de la signature binaire du fichier compressé).

        • [^]Re: Felicitations a ttes l'équipe !

          Posté par golum () le 05/01/2006 à 14:17. (lien). Évalué à 3.

          Oui donc ca revient presqu'au même pour certains types de fichiers d'o l'interet de choisir de versionner ou simplement stocker la dernière version de fichiers. Les SCM ne permettent en général que de choisir entre versionnage ou non mais aucune notion de partage sans versionning.
          
          Puisque je m'adresse à un spécialiste j'en profite: Est il prévu qu'un éditeur ou un projet puisse implementer son propre gestionnaire de stockage de version et de diff/merge en fonction du type de fichier, un peu comme le fait clearcase par exemple ?
          
          En effet, il gère differemment les fichiers Rose ou xml avec un algorithme de stockage dédié mais aussi des interfaces de diff/merge adapté au format du fichier.Tout ceci etant largement configurable.

          • [^]Re: Felicitations a ttes l'équipe !

            Posté par David Anderson (page perso, ) le 05/01/2006 à 14:43. (lien). Évalué à 3.

            Cela est en effet prévu (spécialisation des algos de delta selon le type mime), mais pose encore toute une floppée de problèmes, et l'implémentation est déférrée à "après le merge tracking". C'est une feature prévue et désirée, mais de basse priorité pour l'instant.
            
            Bien sur, si tu te sens l'âme de t'y mettre, je ne pense pas que (sauf excellente raison spécifique d'attendre) ca posera problème. Simplement, les développeurs actuels sont occupés sur d'autres choses.

        • [^]Re: Felicitations a ttes l'équipe !

          Posté par Sytoka Modon (page perso, ) le 07/01/2006 à 10:31. (lien). Évalué à 7.

          > Bon après, si le binaire en question est un .zip (par exemple), c'est
          > sur que la modif d'une ligne d'un fichier dans le zip produit un delta
          > ridiculement gros, mais ca c'est un problème du à la nature du
          
          Dommage que les zip et les tar (gz) ne soient pas pris en compte car les fichiers d'openoffice (swx ou odt) sont des archives zip. Or je ne sais pas pour vous mais j'en vois passer de plus en plus ;-)

          • [^]Re: Felicitations a ttes l'équipe !

            Posté par David Anderson (page perso, ) le 07/01/2006 à 23:34. (lien). Évalué à 5.

            En effet, et c'est même une question posée par rapport au stockage de documents OpenOffice.org dans Subversion qui a amené la question de la façon de procéder. Comme dit ailleurs dans ces commentaires, les modules de diff spécialisés selon les types mime sont sur la feuille de route à long terme, mais pas prévu pour dans l'immédiat.
            
            Le résultat, c'est qu'après une demi-douzaine de hacks proposés pour supporter explicitement le format OOo, il a été proposé autre chose, plus simple et offrant un gain pour plus de monde.
            
            Debian a intégré à sa libz un patch ajoutant une option pour produire des fichiers compressés "rsyncable", c'est à dire ayant une empreinte changeante minimale, pour faciliter les rsync rapides. Il a été suggéré à OOo qu'ils intègrent cette modification algorithmique (qui devrait etre portable aux algos zip), ainsi les deltas entre deux versions d'un fichier se verraient grandement réduits. En le faisant à ce niveau là, le gain n'est pas seulement pour les utilisateurs de Subversion, mais pour la totalité des applications qui se causent en diffs.
            
            Je comprends que cette solution puisse sembler être un passage de la patate chaude, mais il faut aussi voir le contexte : dans le cadre de la discussion sur "est-ce qu'il faudrait traiter les fichiers compressés spécialement?", il y a eu énormément de tentatives de pousser les développeurs à introduire un système similaire à Clearcase, ou tous les fichiers sont spéciaux et gérés différemment. Ca s'est terminé en un affront du type "soit on implémente la spécialisation des diffs maintenant, pour tout, soit on fait rien et on attend de pouvoir le faire correctement". C'est ce dernier, en combinaison avec une suggestion au projet OOo, qui a été retenue, et ce au moins jusqu'a ce que le merge tracking soit implémenté.
            
            Donc, euh, voila. Donc l'état actuel, c'est que les fichiers compressés sont traités comme tous les autres (notez tout de même que c'est toujours mieux que CVS, puisqu'il y a un algo de diff binaire assez efficace), ce qui place Subversion à égalité avec beaucoup d'outils concurrents (à l'exception notable des plus gros, plus anciens et plus commerciaux). Et l'état futur, c'est que c'est l'une des montagnes à l'horizon que nous franchirons sur notre chemin :-)

            • [^]Re: Felicitations a ttes l'équipe !

              Posté par Thomas Douillard () le 08/01/2006 à 13:16. (lien). Évalué à 4.

              Là je me pose une question : si on a un algo génétal pour n'importe quel type de fichier, et qu'on prévoit d'en faire des spécialisés plus tard, pourquoi ne pas implémenter un truc qui utilise des algos spécifiques quand ils sont dispos, et l'algo général sinon ? par exemple par un système de plugin. Ca me semble un compromis acceptable, avec petit à petits des algos spécifiques d'implémentés, mais sans urgence parce qu'il y a de toute façon une solution ...

• [^]Re: Felicitations a ttes l'équipe !

  Posté par bengali () le 05/01/2006 à 13:12. (lien). Évalué à 3.

  Oui j'en fais exactement la même utilisation donc en environnement mono-utilisateur. Les avantages sont la pléthore de clients existant qui s'intègrent au gestionnaire de fenêtres (Tortoise SVN), à l'IDE (sous Eclipse par exemple), aux outils de build (plugins Ant),etc. Le fait de pouvoir se connecter au serveur en ssh est vraiment un + surtout pour passer au travers des firewalls... J'aime bien également les conventions utilisées qui permettent de s'affranchir de configuration comme le répertoire du tronc(trunk), celui des tags et des patchs => tagger une version c'est la copier du tronc vers un sous répertoire de tags.
  
  Je n'ai pas eu l'occasion de l'utiliser en entreprise en environnement multiutilisateurs (c'est quand même l'intérêt). A mon boulot,on utilise ClearCase et on a besoin d'un administrateur. L'administration subversion est très simple, un administrateur système peut s'en occuper facilement. Par contre en terme de fonctionnalités je n'en fais pas une utilisation assez avancée (ni de Subversion, ni de ClearCase) pour dire quel produit est "supérieur " à l'autre.

• [^]Re: Felicitations a ttes l'équipe !

  Posté par David Anderson (page perso, ) le 05/01/2006 à 14:07. (lien). Évalué à 2.

  Le stockage des fichiers en double est un embêtement connu pour certains cas. Pour rappel, une copie de chaque fichier tel qu'il est dans le dépot (nommé text-base) est stockée dans .svn, et ce afin de pouvoir exécuter 'svn diff' (affiche les modifications locales sous forme de diff unifié) sans avoir de connexion au réseau.
  
  Il est prévu à l'avenir de permettre la création d'une copie de travail sans ces text-base, pour avoir une copie de travail moins grosse, au prix de devoir avoir le réseau à disposition même pour les opérations triviales comme 'svn diff' ou 'svn status' (qui devrait demander au serveur pour pouvoir comparer).
  
  L'implémentation de cette fonctionalité était également un projet Summer of Code d'ailleurs, mais la personne qui y a été affectée (qui était déjà un développeur Subversion) a préféré s'atteler à des problèmes plus urgents finalement, et donc ca n'a pas été terminé.

  • [^]Re: Felicitations a ttes l'équipe !

    Posté par xeuzuex () le 05/01/2006 à 14:24. (lien). Évalué à 1.

    Oui mais en fait c'est juste pour les binaires que c'est embetant.
    Les fichiers sont rarement de grosses tailles.
    Par exemple si tu geres des jpg ds ton referenciel, de ttes facons on ne peut pas faire de svn diff. Donc pourquoi le stocker ds le repertoire .svn ?
    Question fonctionnement :
    Il est vrai qu'avec un checksum on doit pouvoir voir si le fichier a été changé. (utile pour le commit)
    En gros est ce que l'operation est pour un commit : "le checksum /titi/toto.jpg est comparé au checksum /titi/.svn/toto.jpg" si ils sont differents alors on enregistre la nouvelle version.
    
    Dans ce cas une question : Pourquoi ne pas stocker juste les checksum des fichiers binaires ds le rep .svn ?

    • [^]Re: Felicitations a ttes l'équipe !

      Posté par David Anderson (page perso, ) le 05/01/2006 à 14:48. (lien). Évalué à 3.

      Le fait que l'interface "par défaut" de Subversion refuse d'afficher les diff de fichiers binaires ne signifie pas que c'est impossible. On pourrait très bien imaginer un autre client (Comme TortoiseSVN par exemple) qui ferait pour les fichiers jpg un affichage visuel des différences entre le fichier d'origine et modifié.
      
      Le problème en vient donc à l'impossibilité de spécialiser proprement le comportement pour les fichiers "binaires" (d'ailleurs, qu'est-ce qui est un fichier binaire? Cette question peut aussi être problématique parfois). On en revient donc au comportement proposé pour l'implémentation: pouvoir activer ou désactiver globalement le stockage du text-base pour une copie de travail. On peut imaginer par la suite un mode hybride, ou le non-stockage serait dicté par (au hasard) une propriété rattachée au fichier.
      
      Dans tous les cas, si tu veux nous aider à trouver une définition qui te plaise au problème (et donc à la solution), je t'invite à venir en parler sur dev@subversion.tigris.org (mailing list de développement du projet), pour voir avec les développeurs spécialistes de la bibliothèque de gestion de la copie de travail où ca en est.

  • [^]Re: Felicitations a ttes l'équipe !

    Posté par golum () le 05/01/2006 à 14:47. (lien). Évalué à 2.

    Une autre approche concernant ce problème est l'utilisation de copie de travail virtuelle en mode connectée.
    
    Les fichiers sont delivrés à la demande (invocation du compilateur, ouverture) et rien n'est véritablement stocké sur la copie de travail hormis les fichiers modifiés ou privés. Bien souvent il s'agit de file system dédié qui intercepte les I/O sur un fichier.
    Ainsi on a les vues dynamiques (MVFS) sous Clearcase, mais d'autres logiciels libres utilisent une approche similaire.
    Ainsi Vesta et Aegis (je crois) .
    http://www.vestasys.org/
    http://aegis.sourceforge.net/
    
    Cette approche présente certains avantages
    (Gain d'espace, possiblité de naviguer rapidement dasn l'historique des versions, outils de partage de build)
    et le lot d'inconvénient qui va avec (lenteur sur certaines opération modèle de développement centralisé, mise à jour de fichiers de son espace de travail non sollicitée)

Type de license?

• [^]Re: Type de license?

  Posté par David Anderson (page perso, ) le 05/01/2006 à 14:18. (lien). Évalué à 1.

  Dans le spectre des licences, la licence de Subversion est proche de la licence Apache, qui elle est une licence dérivée de BSD. Bref, c'est une licence libérale, approuvée par l'OSI, qui permet de faire à peu près ce qu'on veut avec.
  
  Les restrictions ont été ajoutées par Collabnet, l'entreprise qui a lancé le développement en 2000 (en embauchant Karl Fogel, expert CVS, et en lui disant "Tu vois CVS? Tu vois ce qui te plais pas? Code nous un CVS que tu aimerais utiliser" :). Ayant fait le pari de faire de leur SCM un projet entièrement libre, elle a tout de même ajouté des clauses pour protéger ses marques déposées (Collabnet et Tigris).
  
  Donc, pour résumer, c'est pas aussi libre que la GPL, parce que Collabnet et d'autres veulent une licence type BSD pour pouvoir développer des composants propriétaires (pour Collabnet, c'est notamment les modules d'intégration à leur produit de groupware); mais c'est vraiment libre, d'après l'OSI et les DFSG (Debian Free Software Guidelines). J'ai un doute pour la FSF, donc je vais la fermer au lieu de risquer de dire une connerie. Allez vérifier :P

  • [^]Re: Type de license?

    Posté par djano () le 05/01/2006 à 18:53. (lien). Évalué à 3.

    D'apres ce que j'ai vu sur le site de Subversion, la license utilisée est une Apache version 1.1.
    Donc si on regarde sur le site de GNU a la bonne page, (http://www.gnu.org/licenses/license-list.fr.html), on trouve ca:
    
    

    
    La licence d'Apache version 1.0.
    
    C'est une licence simple et permissive de logiciel libre sans gauche d'auteur présentant des problèmes pratiques semblables à ceux de la license BSD, avec y compris l'incompatibilité avec la GPL de GNU.
    
    La Licence d'Apache version 1.1.
    Licence de logiciel libre sans gauche d'auteur, permissive, avec quelques aspects qui la rendent incompatible avec la GPL de GNU.
    
    Nous vous demandons instamment de ne pas utiliser les licences d'Apache pour les logiciels que vous écrivez. Toutefois, il n'y a aucune raison d'éviter de faire fonctionner les logiciels publiés sous cette licence, Apache par exemple.
    

    
    
    Donc on est pas trop avance, mais si on regarde la licence Apache v1.0, et en supposant que ce sont les memes problemes qui sont present dans la v1.1, alors ce sont les memes que ceux de la license BSD originale, c'est a dire la citation des auteurs il me semble.

    • [^]Re: Type de license?

      Posté par Krunch (Jabber id, page perso, ) le 07/01/2006 à 17:22. (lien). Évalué à 4.

      si on regarde la licence Apache v1.0, et en supposant que ce sont les memes problemes qui sont present dans la v1.1, alors ce sont les memes que ceux de la license BSD originale, c'est a dire la citation des auteurs il me semble.

      Lis les licences. Cette clause était présente dans la licence Apache 1.0 mais plus dans la 1.1. Le problème restant semble plutôt concerner l'utilisation du nom du logiciel original (comme pour la MPL je pense).

      --
      Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
      pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

  • [^]Re: Type de license?

    Posté par Krunch (Jabber id, page perso, ) le 07/01/2006 à 17:32. (lien). Évalué à 6.

    Donc, pour résumer, c'est pas aussi libre que la GPL, parce que Collabnet et d'autres veulent une licence type BSD pour pouvoir développer des composants propriétaires

    C'est pas pour lancer un troll GPL/BSD mais la licence BSD est plus libre que la GPL dans le sens où tu n'es pas obligé de redistribuer les sources avec. Il y a une contrainte en moins donc de la liberté en plus (bon après le troll commence quand on se demande s'il vaut mieux garder une contrainte permettant de conserver la liberté a posteriori ou s'il vaut mieux la retirer pour avoir plus de liberté dans l'immédiat).
    
    La licence SVN/Apache 1.1 est aussi plus libre que la GPL dans le sens où on n'est pas obliger de redistribuer les sources (comme pour la BSD) mais moins libre dans le sens où on ne peut pas réutiliser le nom "Tigris" aussi librement. Apparement les GPListes pensent que cette restriction n'a rien à faire dans la licence et devrait être gérée au niveau des marques déposées.

    --
    Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
    pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

    • [^]Re: Type de license?

      Posté par David Anderson (page perso, ) le 07/01/2006 à 23:56. (lien). Évalué à 3.

      Désolé, mais si, c'est quand même un peu pour lancer un troll, avoue ;-)
      
      Je suis d'accord avec ton évaluation des licences. Simplement, j'ai parlé avec mes mots à moi, et dans mon système de valeurs une licence garantissant la liberté dans la durée et la totalité mérite plus l'apellation 'libre'. Toujours pour moi, la BSD est plus permissive, oui, mais pas plus libre.
      
      Oui, ce ne sont que des nuances de vocabulaire sur lesquelles on pourrait s'entredéchirer pendant des mois. Mais comme je l'ai dit précédemment, c'est dans mon système de valeurs, et c'est totalement personel. À vous d'avoir le votre, peut-être différent du mien. Le mien m'a échappé dans mes formulations et est devenu un troll en lancement potentiel, ben "oups", c'était pas fait exprès.
      
      Donc GPL, BSD, MPL, CCL (CoinCoin Licence), tout l'égout est dans la nature ;-)
      
      En ce qui concerne les marques déposées, la question (à mon avis, IANAL) est de savoir quels recours légaux sont disponibles dans l'éventualité d'une violation. Est-ce qu'une marque déposée aux US peut faire valoir sa marque dans d'autres pays? Est-ce que mettre la contrainte dans la licence ne donne pas plus de poids juridique, puisqu'en cas de violation, les droits qui t'incombaient avant sont révoqués par l'acte même de transgression, plutot que par une décision de tribunal quelques mois plus tard?
      
      Enfin j'en sais rien en fait, et je devrais arrêter d'énoncer des hypothèses qui doivent écorcher les oreilles de nos amis juristes :-)
      
      Bref, voila, mea culpa sur le petit lapsus de conviction personelle, j'espère que ca ne partira pas en troll complet!

Et un vrai systeme de merge ?

• [^]Re: Et un vrai systeme de merge ?

  Posté par golum () le 05/01/2006 à 13:54. (lien). Évalué à 4.

  
  Alors: c'est pour quand ?
  

  
  
  http://subversion.tigris.org/roadmap.html
  

  
  # Medium-term Goals:
  ...
  Merge tracking (see notes)
  

  
  
  la 2.0 ?

• [^]Re: Et un vrai systeme de merge ?

  Posté par David Anderson (page perso, ) le 05/01/2006 à 14:39. (lien). Évalué à 10.

  Ne t'inquiète pas, maintenant que le backend FSFS est stabilisé et que le support du vérouillage est complet (introduit dans svn 1.2), le "merge tracking" est le prochain changement majeur (dans la catégorisation de mon article, ca serait dans la catégorie "über-changements", au dessus de "ameliorations majeures" ;-) prévu pour l'implémentation. Comme dirait l'un des fondateurs du projet "C'est la grosse montagne à l'horizon. Et on est sur le chemin qui y va."
  
  Là encore, pour ceux qui trouvent que c'est lent, on est pas immobiles. Déjà, Collabnet organise d'ici quelques jours une réunion de ses gros clients, pour leur demander ce que eux, en tant que développeurs, entendent par "Gestion des merges" (on dirait peut-être pas, mais on peut implémenter une immense variété de comportements derrière ce nom vague, avec des dizaines d'UI possibles par implémentation). Une fois que nos développeurs de Collabnet (les seuls payés à plein temps pour subversion) ont le feedback des clients, la question sera posée aux utilisateurs de Subversion en général. Après, l'ensemble des résultats sera digéré, une spécification sera pondue, et l'implémentation démarera.
  
  Juste une petite note concernant la procédure : la question est d'abord posée aux clients de Collabnet parce que nous pensons que leurs ingénieurs et chefs de projet sont à même de nous dire précisément et avec un minimum d'ambiguité ce qu'ils veulent, et que d'avoir quelques définitions claires pourrait aider le "grand public" libre à donner des réponses utiles, plutot que des tautologies du type "on veut un suivi des merges!". Ce n'est absolument pas pour favoriser les clients de Collabnet, et je peux vous assurer que les développeurs de Subversion non-employés par collabnet, une majorité dont je fais partie ne se laisseront pas faire (même s'il n'y a jamais eu besoin de se battre - Collabnet à toujours oeuvré dans le respect complet du "code moral" des projets libre).
  
  Donc voilà, c'est en marche, mais je ne cache pas que cela prendra du temps. Et oui, je suis au courant que nombre de systèmes de contrôle de révision implémentent déjà quelque chose, mais nous préférons bien comprendre le problème avant d'implémenter une solution qui ne fait que la moitié de ce qu'on attend d'elle ;-) Mais réalistiquement, je ne pense pas qu'il faille s'y attendre avant subversion 1.6 au plus tôt (estimation powered by pifomètre, désolé). En attendant, l'utilisation de svnmerge et svk est recommandée pour la gestion des merges, ce sont de bons logiciels (et on se privera pas de leur piquer des idées le moment venu ;-)

  • [^]Re: Et un vrai systeme de merge ?

    Posté par golum () le 05/01/2006 à 15:58. (lien). Évalué à 4.

    Ne serait t'il pas également judicieux de vous inspirer des travaux d'autres logiciels de SCM libres.
    Notamment les devs de SCM distribués ont déjà pas mal traité la problématique des merges qui est encore plus sensible pour ce type de logiciels.
    
    L'initiative de wiki collaboratif entre projets me paraissait intéressante comme point d'échange
    http://revctrl.org/FrontPage
    D'autant que certains contributeurs de SVN semblent participer.
    
    Nathaniel smith (monotone) et Brad Cohen (codeville) ont aussi pas mal dégrossi le travail dans la ml de monotone
    http://article.gmane.org/gmane.comp.version-control.monotone(...)

  • [^]Re: Et un vrai systeme de merge ?

    Posté par vieuxshell () le 05/01/2006 à 18:36. (lien). Évalué à 3.

    Ahhh en voilà une nouvelle qu'elle est bonne.
    
    J'étais un petit peu "anxieu" car la derniere info que j'avais lue était une remarque de Karl Fogel sur @dev du style "on a pas le temps de bosser dessus pour l'instant".
    
    Du coup c'est plutôt bien si le train est en gare pret à partir.
    
    Sinon, est-il prévu (si ca a été discuté) de permettre un "import" du merge history à partir des systemes existants (genre svk) ?
    
    (c'est pratique d'avoir un contributeur, release manager "sous la main" quand même :D)