- 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.
Aller plus loin
- Site officiel de Subversion (23 clics)
- Notes de version, à lire absolument ! (6 clics)
- Subversion’s Future? (2 clics)
- Carte de référence rapide (PDF, 2 pages, 81 Ko) (4 clics)
- Module pour empêcher le checkout à la racine (très utile, neuneu-proof) (2 clics)
- SVK : VCS décentralisé basé sur Subversion (2 clics)
# Centralisé et Décentralisé
Posté par vincent_k (site web personnel) . Évalué à 7.
[^] # Re: Centralisé et Décentralisé
Posté par ribwund . Évalué à 4.
[^] # Re: Centralisé et Décentralisé
Posté par Nÿco (site web personnel) . Évalué à 4.
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_(...)
[^] # Re: Centralisé et Décentralisé
Posté par BAud (site web personnel) . Évalué à 8.
- 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é
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4.
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é
Posté par Misc (site web personnel) . Évalué à 10.
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é
Posté par vincent_k (site web personnel) . Évalué à 2.
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é
Posté par Victor STINNER (site web personnel) . Évalué à 5.
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é
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
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é
Posté par Victor STINNER (site web personnel) . Évalué à 2.
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é
Posté par ZeroHeure . Évalué à 3.
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).
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Centralisé et Décentralisé
Posté par ocroquette . Évalué à 4.
[^] # Re: Centralisé et Décentralisé
Posté par Antoine . Évalué à 2.
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é
Posté par wilk . Évalué à 1.
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...
# Beurk
Posté par Sylvain Sauvage . Évalué à 10.
quanT
# Merge
Posté par ckyl . Évalué à 3.
J'ai pas encore testé la 1.5 mais c'est une très mauvaise nouvelle.
C'est LA lacune de SVN. Impossible de gérer des branches, ca foire à chaque fois et on fini par faire un diff/patch à la main.
La seule façon de merger des branches sur un serveur subversion que j'ai trouvé c'est d'utiliser git-svn (qui envoi du paté)...
[^] # Re: Merge
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Merge
Posté par Alban Crequy (site web personnel) . Évalué à 5.
http://www.orcaware.com/svn/wiki/Svnmerge.py
Avec svnmerge.py, ca marche très bien, à la fois pour tirer une branche de temps en temps et pour le cherry picking. On peut merger dans tous les sens. Les commits d'une branche intégrés dans une autre sont sauvegardés dans la propriété SVN svn-integrated si je me souviens bien, et ça marche tout seul :-)
Faire un diff/patch à la main... heu...
git-svn est pas mal (je l'utilise quand un projet utilise SVN pour directement travailler avec git) mais je ne sais pas s'il s'intégre correctement à svnmerge.py. Si les collaborateurs du projet utilisent svnmerge.py et que d'autres utilisent git-svn, je peur que le suivi des opérations de merge en patisse...
[^] # Re: Merge
Posté par ckyl . Évalué à 6.
svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.
Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.
Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:
1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.
2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !
3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.
4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.
Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.
Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.
[^] # Re: Merge
Posté par zul (site web personnel) . Évalué à 3.
Après, on peut toujours aimer se tortuer l'esprit en passant par git-svn ou git-autretruc jusqu'au jour ou un fait un truc un peu r00t pas forcément prévu.
Enfin, git n'est probablement pas la solution ultime aujourd'hui, même si en tant que VCS, il poutre pas mal la concurrence amha. Il reste le facteur du portage Windows et l'intégration àlaturtoise.
[^] # Re: Merge
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
C'est un des soucis aujourd'hui, subversion est bon moyennant ce problème de merge de branche et les autres sont bon aussi moyennant l'aspect multi-plateforme et facilité pour l'utilisateur lambda.
Un de mes objectifs est de fédérer le développement pour des utilisateurs lambda dont une bonne partie est sous Windows, projets qui ont un développeur principal. Donc je suis parti sur quelque chose de simple qui apporte une réelle plus value rapidement : trac + svn.
Il est clair que quelques utilisateurs avancés (dont moi !) arrivent rapidement aux limites de cet environnnement. Mais globalement, j'aurais mis un git en place que seuls ces quelques utilisateurs l'auraient utilisé, et je ne serais pas plus avancé aujourd'hui.
[^] # Re: Merge
Posté par ribwund . Évalué à 3.
http://tortoisehg.sourceforge.net/
[^] # Re: Merge
Posté par ckyl . Évalué à 3.
Et effectivement l'intégration de git dans eclipse/netbeans/idea actuellement c'est vraiment pas ça. C'est de toute façon un facteur bloquant pour migrer.
[^] # Re: Merge
Posté par Julien Portalier . Évalué à 2.
Mais les branches sont en effet lourdes à gérer, subversion n'est pas (encore) vraiment adapté à la gestion de branches, et apparemment c'est toujours pas prêt de devenir simple. Ça marche, mais il faut bien tout noter : à quelle révision on a créé la branche ; la dernière révision du merge avec le trunk ; la dernière révision du merge back ; etc.
[^] # Re: Merge
Posté par Alban Crequy (site web personnel) . Évalué à 3.
Ces informations sont enregistrées automatiquement dans une propriété SVN lorsqu'on utilise svnmerge.py. Comme le note cykl, l'outil n'est pas parfait. Mais c'est tout de même mieux que d'utiliser les outils SVN de base.
[^] # Re: Merge
Posté par Mildred (site web personnel) . Évalué à 3.
C'est pour cela que je n'aime pas trop utiliser svn pour des choses un peu complexe.
Par contre l'avantage de svn par rapport aux dvcs c'est qu'il est possible de décomposer un projet en sous projets, et de faire un checkout du sous projet uniquement. J'aimerais bien voir la même chose dans Mercurial (prévu mais pas implémenté).
[^] # Re: Merge
Posté par or zax . Évalué à 3.
[^] # Re: Merge
Posté par Laurent Morel . Évalué à 3.
Comme c'est très complexe (et qu'ils ont placé la barre très haute je crois) il n'ont pas pu tout faire encore. Mais dans les cas standard, c'est simple :
http://blog.red-bean.com/sussman/?p=92
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.