Logiciel : Subversion (SVN) 1.5 est disponible
Posté par Nÿco (Jabber id, page perso, ). Modéré le 21 juin 2008.
0
Subversion, ou svn pour les intimes, le célèbre logiciel libre sous licence Apache/BSD du type gestion centralisée de versions (VCS) a été publié en version 1.5. Conçu à l'origine en 2000 pour remplacer CVS et ses limitations, cette version apporte de nombreuses améliorations :
- Suivi des opérations de Merge (merge tracking) (implémentation non complète) ;
- Sparse checkouts (via une nouvelle option --depth) ;
- Résolution de conflit interactive ;
- Prise en charge des listes de changements (changelists) ;
- URL relatives, peg revisions dans svn:externals ;
- Prise en charge de Cyrus SASL pour ra_svn et svnserve ;
- Prise en charge améliorée pour les déploiements à grande échelle de FSFS, via le sharding ;
- Optimisations possibles améliorées de FSFS, via l'isolation immuable de fichiers ;
- Proxy WebDAV d'écriture directe (write-through) transparent ;
- Améliorations de la copie et du déplacement ;
- Améliorations en vitesse, amélioration des temps de réponse des annulations ;
- Plus facile d'essayer le module expérimental d'accès ra_serf DAV ;
- Changement dans les API, améliorations et beaucoup de travail de bindings de langages ;
- Plus de 150 corrections de bugs et améliorations.
Subversion 1.X ayant effectivement réussi à remplacer CVS dans de nombreux cas, y compris de complexes ou à large échelle, ces dernières années ont vu s'épanouir et monter en puissance des solutions de VCS décentralisées, bien évidemment libres, telle que git issu du monde du noyau Linux et Mercurial (Hg). Le projet Subversion s'interroge à ce sujet quant à son avenir.
![[en]](../images/en.png)
Site officiel de Subversion (444 hits)-
Notes de version, à lire absolument ! (435 hits)
-
Subversion’s Future? (664 hits)
-
Carte de référence rapide (PDF, 2 pages, 81 Ko) (784 hits)
-
Module pour empêcher le checkout à la racine (très utile, neuneu-proof) (237 hits)
-
SVK : VCS décentralisé basé sur Subversion (228 hits)
> Lire les commentaires (28 commentaires, moyenne: 4).
Vous avez demandé le commentaire #942998.
Run by 
Cette page a été générée par Templeet en 0.0884s (dont 0.017 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Centralisé et Décentralisé
je me pose la question de savoir quels sont les avantages et les inconvénients des deux systèmes?
[^]Re: Centralisé et Décentralisé
On a pas deja eu 10.000 threads (trolls?) dessus ? A mon avis tu google, tu cherche les anciennes depeches sur git/mercurial/bzr/darcs et tu trouveras ce que tu cherche.
[^]Re: Centralisé et Décentralisé
Y'a du gros boulot à faire sur ces articles, mais ça peut t'aider :
http://en.wikipedia.org/wiki/Version_control_system
http://en.wikipedia.org/wiki/Distributed_revision_control
http://en.wikipedia.org/wiki/Comparison_of_revision_control_(...)
Jabber ID : xmpp:Nyco@jabber.fr
[^]Re: Centralisé et Décentralisé
Tu peux te poser les questions suivantes :
- suis-je toujours connecté à Internet ?
- des commits réguliers permettent-ils d'avoir un meilleur suivi du changelog par fonctionnalité implémentée ?
- de plus petits commits facilitent-ils la gestion des conflits d'édition ?
- release-early/release often fonctionne-t-il bien en décentralisé ?
- combien de contributeurs travaillent sur des fonctionnalités décorrélées ?
- à quelle cadence est-il nécessaire d'avoir une version rassemblant toutes les contributions en cours ?
- quel est le plus simple pour les utilisateurs du dépôt pour avoir une version homogène ayant le plus de fonctionnalités ?
[^]Re: Centralisé et Décentralisé
Si tu veux des avis subjectifs, tu as celui de Linus qui a créé Git (décentralisé). Il s'agit d'une conférence qu'il a donné chez Google :
http://video.google.com/videoplay?docid=-2199332044603874737
Tu as aussi un avis sur cette conférence ici : http://thomas.enix.org/Blog-20070805231406-Technologie&s(...)
Et concernant les journaux, voici un autre point de vu, principalement sur les décentralisés là aussi :
https://linuxfr.org/~NoNo/26146.html
https://linuxfr.org/~NoNo/26309.html
[^]Re: Centralisé et Décentralisé
Je sais pas si ça peut t'aider, mais la conférence sur mercurial des journées pythons francophones de cette année peut t'éclairer https://linuxfr.org//2008/06/03/24172.html ( J'ai fait la conférence ).
Je te conseille la lecture du livre sur bzr ( http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html ) la partie sur les workflows, de voir les conférences sur git, etc, sur google video.
En tapant git vs svn, bzr vs darcs, etc sur un moteur de recherches, tu peut aussi trouver de nombreux articles sur ça.
En général, ce qui va en ressortir, c'est que git est complexe, que bzr est simple, que hg et git sont rapides, et que beaucoup de gens vont dire que les vcs centralisés, c'est pourri ( ce qui à mon sens n'est pas vrai ).
Il faut bien voir que c'est avant tout une question de processus de travail, et d'outils. Il y a pas de raison de changer ce qui marche, donc, avant d'envisager une migration, il faut savoir pourquoi.
La plupart des dvcs ne sont pas optimaux pour des projets avec des gros fichiers dans l'historiques, car cela consomme une place conséquente. De même, l'intégration des outils avec svn est en général mature, alors que pour la plupart des systèmes récents, c'est pas encore ça ( je pense notamment à des outils proprios, comme xcode, visual c++, mais aussi des applications libres comme trac ( même si ça a récemment changé pour trac ) ou review board ( http://www.review-board.org/ ) )
Il faut également prendre en compte les gens de ton équipe ( si il y en a ), qui peuvent avoir autre chose à faire que d'apprendre un nouveau systéme. Et il y a également un facteur à prendre en compte, c'est que personne ne conteste la prédominance de svn dans le monde des vcs centralisés, mais par contre, dans le monde des dvcs, le consensus n'est pas la, ( exemple : http://lists.freebsd.org/pipermail/freebsd-current/2008-June(...) )
Pour ma part, j'ai l'impression que beaucoup de gens qui migrent, migrent vers git, aussi bien de svn, que de systèmes comme mercurial ( exemple, alsa ) que monotone ( exemple, openmoko ).
Parmi les gros utilisateurs de mercurial, on peut trouver sun ( qui se standardise sur mercurial ( http://opensolaris.org/os/community/tools/scm/ ), xen, et d'autres.
La page de sun explique bien les divers problématiques et les raisons de leur choix.
Pour bzr, j'ai par contre l'impression que ça tient plus du choix philosophique. Emacs migre parce rms a dit "faut utiliser un projet gnu" ( http://lwn.net/Articles/272853/ ), mysql migre pour avoir un système plus libre que bk , et parce que canonical a corrigé les problèmes pour mysql, ( http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks(...) ).
Donc, c'est une question ouverte, un troll multi niveau qui a de l'avenir, pour remplacer les traditionnels "java ça pues, suse c'est pas libre, et flash c'est nul". Surtout que les dvcs bougent trés vite, copiant les fonctionnalités de l'un à l'autre à tout bout de champ ( exemple, git-svn repris par bzr, git ayant repris et amélioré le commit interactif de darcs ), ou en rajoutant certaines très intéressante ( http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n(...) , http://kerneltrap.org/node/11753 )
[^]Re: Centralisé et Décentralisé
En voilà un commentaire qui m'aide (un peu :) )
Je n'ai aucun à priori sur la supériorité de tel ou tel système, j'ai juste testé Subversion en local et j'avais trouvé ça marrant. Et vu que je ne suis pas encore dévellopeur, je ne peux pas dire si telle ou telle feature est intéressante où pas.
Faudrait que je teste Git et Bazaar, mais ça va être difficile de comparé quand on a pas de travail à mettre en commun :p
[^]Re: Centralisé et Décentralisé
misc m'a convaincu de tester Mercurial. En fait, la semaine où j'ai lancé mon projet Hasard, j'errais entre le train et l'hôtel, deux lieux généralement dépourvus d'Internet (gratuit). En gros, il suffit de remplacer "svn" par "hg" dans la ligne de commande. Pour publier son travail (et faire une sauvegarde), il faut faire "hg push" de tant à autre. Mercurial marche très bien avec Apache et SSH. Quand on veut récupérer les modifications des autres, "hg pull" ne suffit pas. Il faut aussi faire "hg update" et "hg merge", chose assez déroutante quand on vient de Subversion.
Quelques remarques personnelles sur svn VS hg :
- je commite très souvent car c'est instantané (c'est un peu comme passer de cvs diff à svn diff !) et ça coûte pas cher. Je dois faire 4 à 10x plus de commits, qui sont donc plus petits, plus facile à relire, et c'est aussi plus facile à annuler.
- on peut supprimer ses derniers commits avec "hg strip", là où subversion est totalement figé : interdiction absolue de supprimer du code (même si on a commité /etc/shadow ou des photos perso)
- mis à part hg push et hg pull, toutes les opérations sont instantanées, ça fait limite peur au début :-)
- hg push envoie N commits d'un coup alors que svn ci n'envoie qu'un commit
- hg revert conserve une copie du fichier modifié (c'est optionnel : hg revert --no-backup)
- hg ci quitte si le changelog est vide (c'est très positif :-))
- j'ai merdé : j'ai mis plusieurs dizaines de mégaoctets de fichiers de test dans mon dépôt par erreur. Du coup, le dépôt pèse 40 Mo alors que les sources font juste 40 Ko (en virant l'historique avec "rm -rf .hg*"). Je pense qu'avec l'expérience, je ne ferai plus cette erreur (ex: "hg strip" pour virer des commits).
[^]Re: Centralisé et Décentralisé
Merci pour ce commentaire très sympa, j'ai bien envie de me mettre à un dvcs mais bazaar ne me motive pas et git a l'air hype mais vraiment over compliqué (je cherche plutot comme dit ici un svn ou on peut commit en local)
2 petites questions sur mercurial :
- est-ce qu'on peut merger des commits locaux avant de "pusher" les changements ? (par exemple j'ai 5 commits sur ma tache A et 4 sur ma tache B, je veut envoyer 2 commits pour la tache A et B, de manière propre)
- est-ce qu'on a des dossiers .hg partout, comme svn, ou c'est propre comme git ? :)
[^]Re: Centralisé et Décentralisé
- est-ce qu'on peut merger des commits locaux avant de "pusher" les changements ?
Ah, ça je sais pas. Je suppose que oui. Selon un ami, cette extension (incluse de base) devrait faire l'affaire :
http://www.selenic.com/mercurial/wiki/index.cgi/TransplantEx(...)
est-ce qu'on a des dossiers .hg partout, comme svn, ou c'est propre comme git ? :)
À la racine, il y a un dossier ".hg" qui contient 99% des infos. Sinon, il existe .hgignore qui contient les listes des fichiers à ignorer pour la commande "hg stat" (la syntaxe est sex : on peut mélanger les motifs "glob" et motifs "regex"). Enfin, j'ai un fichier ".hgtags" qui contient les tags. Je ne sais pas pourquoi ce fichier n'est pas dans .hg !? RTFM disait Mao.
[^]Re: Centralisé et Décentralisé
D'après les développeurs de Subversion (cf le lien "Subversion’s Future"):
Les systèmes de gestion décentralisés sont l'avenir pour beaucoup de projets, en particulier les projets libres, cependant qu'un système centralisé conserve tout son intérêt pour des projets d'entreprise. Ce qui se conçoit aisément. Ils notent d'ailleurs la croissance vertigineuse du nombre d'adoptions de Subversion en entreprise. Enfin, Subversion sera vraisemblablement le dernier centralisé développé en libre (c'est la fin d'un modèle).
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: Centralisé et Décentralisé
Je parlerais plutôt d'un aboutissement que d'une fin. Il est toujours activement développé, et comme indiqué dans l'article "Subversion's future", le nombre de projets l'utilisant augmente toujours.
[^]Re: Centralisé et Décentralisé
Enfin, Subversion sera vraisemblablement le dernier centralisé développé en libre (c'est la fin d'un modèle).
Surtout qu'il est trivial d'utilisé un système décentralisé de façon centralisée. Qui peut le plus peut le moins.
[^]Re: Centralisé et Décentralisé
Je n'ai pas tellement suivit l'évolution de svn, mais j'aimerai préciser que l'intérêt des "décentralisé" n'est pas que d'être décentralisés. Du reste ils peuvent également être utilisé en mode centralisé ! (l'inverse aussi d'ailleurs).
Personnellement, travaillant la majorité du temps seul et voyageant plutôt à vélo qu'en avion, je me décentralise rarement. Pourtant je profite énormément de bazaar. Pour ce que j'avais du mal a faire avec cvs :
Je crée pleins de branches (c'est rapide et léger).
Une par fonctionalité, bug.
Une par client (qui n'utilisent pas tous la même version).
Ce que j'aime bien avec bazaar c'est qu'après une fusion je garde dans les logs une trace visible (indenté) de quoi a été fait pour qui.
Ca donne quelque chose du genre (qui il me semble ne rend pas comme ça avec hg ou git)
revno : 1234
date ...
message :
merge bs
revno : xxx
message :
entete en couleur pour bs
revno : yyy
message :
tri demandé par machin de chez bs
revno: 1233
date ...
message :
merge bug trucmuch
revno : xxx
message :
finalisation de la correction
revno : xxx
message :
1ere tentative de correction
etc. Donc chaque étape regroupant plusieurs commits dans une branche à part reste bien visible. Une étape peut également montrer une autre étape s'il y a un merge entre deux branches (indenté d'avantage etc.).
Ensuite, si je souhaite montrer le code à un collègue il y a bien sur tout un tas de possibilité de push pull & co, automatique ou non...