Subversion est un système de contrôle de révision, développé dans le but de remplacer CVS comme norme du contrôle de révision dans le monde du libre. La version 1.0 est sortie au terme de 5 ans de conception et développement sponsorisé par l'entreprise Collabnet, et regroupe maintenant une communauté très active. Un grand nombre de projets libres importants ont depuis migré vers Subversion (on notera par exemple les projets KDE et Gcc, ainsi que l'Apache Software Foundation).
Les deux améliorations majeures sont l'extension du contrôle d'accès par ACL aux deux serveurs, qui n'était auparavant utilisable qu'avec le module pour Apache 2, une refonte majeure des bindings Python et l'intégration de bindings Ruby très complets. Et bien entendu, un nombre d'améliorations mineures et de corrections de bugs. Résumé des améliorations
Comme indiqué au dessus, l'une des améliorations majeures est un support plus complet du contrôle d'accès par ACL. Auparavant, pour avoir un contrôle plus fin sur qui peut lire/modifier quoi, il fallait utiliser les module Apache 2, mod_dav_svn et mod_authz_svn. Cela nécessitait l'installation et la configuration d'un serveur Apache 2, ce qui n'est pas forcément du goût de tout le monde. Subversion 1.3.0 permet maintenant aux utilisateurs du serveur indépendant svnserve de profiter du même système d'authz que les utilisateurs de mod_authz_svn, que ce soit pour un accès via svn:// ou svn+ssh:// .
L'autre amélioration majeure se situe dans les bindings, qui permettent à des développeurs d'interfacer directement avec les bibliothèques Subversion depuis d'autres langages que le C (actuellement : Perl, Python, Ruby, Java). Les bindings Python se voient massivement refondus, avec notamment la gestion automatique de la mémoire (avant, il fallait gérer soi-même la mémoire passée aux fonctions de l'API, l'horreur). Les bindings Ruby ont été développés et amenés à maturité.
Les autres améliorations moins vastes que l'on peut trouver sont:
- Le support du logging dans mod_dav_svn, pour stocker un historique des opérations svn (checkout, commit, ...) au lieu d'un historique des requêtes WebDAV (car 1 opération svn = N requêtes WebDAV complexes).
- L'ajout d'options à certaines commandes, notamment pour proposer certaines informations dans un format XML documenté.
- Les connexions via http:// ou https:// sont maintenant interruptibles (par Control-C), grâce à une nouvelle version de Neon (bibliothèque de client WebDAV).
- Le support officiel du "_svn hack", nécéssaire pour pouvoir utiliser Subversion avec certaines versions d'ASP.Net qui interdisent l'utilisation de '.' comme préfixe de répertoire (exit les répertoires ".svn" donc). Ce hack, évidemment optionnel, peut-être activé à l'aide d'une variable d'environnement.
- Quelques améliorations au niveau de la vitesse de certaines opérations comme 'status', 'log' ou 'blame'.
Les développeurs
Cette version est la première à sortir depuis la participation de Subversion au Google Summer of Code. Pour Subversion, cette participation a été riche en retours : les trois améliorations majeures sont des projets SoC, et deux des étudiants SoC sont devenus "Full Committers", c'est à dire qu'ils ont obtenu l'accès en écriture au dépôt principal, et qu'ils peuvent contribuer sans passer par une revue de patch.
Petite note d'égocentrisme, votre serviteur (moi quoi) était l'un des étudiants sélectionnés pour bosser sur Subversion. J'ai bossé sur l'extension de la gestion du contrôle d'accès, suis devenu "Full Committer" et suis maintenant également "Release Manager" pour le projet : c'est moi qui ai préparé, publié et annoncé les fichiers pour cette nouvelle version.
Comme quoi, le Summer of Code ce n'était pas que des "Bounties" que des étudiants rapaces collectent un coup comme ça, c'est aussi des gens qui l'utilisent comme tremplin pour s'impliquer sur un plus long terme dans la communauté du libre!
Aller plus loin
- L'annonce officielle (1 clic)
- Le site du projet (3 clics)
- Les Release Notes (2 clics)
# Merci
Posté par tuiu pol . Évalué à 9.
# Summer of Code
Posté par Pinaraf . Évalué à 6.
C'est mon cas avec Looking Glass, mais plusieurs autres étudiants qui continuent à contribuer même après le summer of code... Notamment ceux qui ont contribué à wine (si je me souviens bien des newsletters de wine)
[^] # Re: Summer of Code
Posté par David Anderson . Évalué à 10.
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 . Évalué à 0.
[^] # Re: Summer of Code
Posté par Pinaraf . Évalué à 7.
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...
Posté par gael75 . Évalué à 6.
Mais j'attends tjrs avec impatience la commande obliterate !!!
Car c'est long et pas marrant de se taper un dump/import lorsque son ami coder a importé sa lib préférée de 100Mo dans svn !
Et ca semble pas pour tout de suite :
http://subversion.tigris.org/issues/show_bug.cgi?id=516
[^] # Re: Bravo mais...
Posté par Anonyme . Évalué à 6.
- 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 . Évalué à 5.
- 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 . Évalué à 10.
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 . Évalué à -2.
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 . Évalué à 10.
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 (site web personnel) . Évalué à 10.
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 . Évalué à 3.
* 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 . Évalué à 4.
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
Posté par dripple . Évalué à 1.
Ici, nous utilisons WSAD + ClearCase, mais je me tâte depuis quelques temps pour faire un proto WSAD + svn.
Si il existe des guides pour n00b, je suis preneur... :-)
[^] # Re: Guide de l'utilisateur en français
Posté par Jérôme FIX (site web personnel) . Évalué à 5.
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 . Évalué à 2.
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 !
Posté par xeuzuex . Évalué à 4.
Ce soft est vraiment top ! Je m'en sers pour tout :
- gerer mes devs ( petits devs)
- Gerer mes données perso entre mon laptop et mon PC fix... explication : Ts mes documents sont sous svn , et je commit les documents sur le dernier PC sur lesquels je les ai modifiés ! donc mon PC/laptop sont quasi tjrs up to date !
Le seul truc c'est que ca prend de la place, vu que ts les fichiers sont dupliqués ds les repertoires .svn . En plus je ne pense pas que cela soit utile pour les fichiers binaires ??
[^] # Re: Felicitations a ttes l'équipe !
Posté par Frédéric COIFFIER . Évalué à 4.
http://www.cis.upenn.edu/~bcpierce/unison/
[^] # Re: Felicitations a ttes l'équipe !
Posté par xeuzuex . Évalué à 3.
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 . Évalué à 4.
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 . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 7.
> 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 . Évalué à 5.
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 . Évalué à 4.
[^] # Re: Felicitations a ttes l'équipe !
Posté par bengali . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 3.
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 . Évalué à 2.
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?
Posté par sylware . Évalué à 2.
[^] # Re: Type de license?
Posté par David Anderson . Évalué à 1.
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 . Évalué à 3.
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:
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 (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Type de license?
Posté par Krunch (site web personnel) . Évalué à 6.
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.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Type de license?
Posté par David Anderson . Évalué à 3.
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 ?
Posté par vieuxshell (site web personnel) . Évalué à 8.
Mais (il y a toujours un mais) il manque -à mon sens- la feature: une vrai gestion des merges. En effet, Subversion, c'est merveilleux on peut créer des branches en veux-tu en voilà très rapidement, pour faire une gestion de conf propre c'est vraiement l'idéal.
Mais pour merger, dès que l'on sort du cas simple "open branch, modif, merge, close branch" ca devient vite bordelique (si la branche à été déplacée, si il y a des merges des les 2 sens, des merges multiples, etc...).
Alors: c'est pour quand ?
En attendant on peut tjrs regarder vers les alternatives:
* svk
* svnmerge
Mais une solution built-in serait quand meme + pro(pre|fessionnelle)
Encore merci pour ce super outil!
[^] # Re: Et un vrai systeme de merge ?
Posté par golum . Évalué à 4.
http://subversion.tigris.org/roadmap.html
la 2.0 ?
[^] # Re: Et un vrai systeme de merge ?
Posté par David Anderson . Évalué à 10.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 3.
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)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.