alors que tout fonctionnait parfaitement encore le 7 janvier dernier, aujourd'hui plus rien ne marche depuis mon client svn
à force de chercher et de demander partout (sans aucun retour) je me replonge encore, désespéré, dans la doc et je tombe finalement sur ce qui semble être ma réponse : Sunsetting Subversion support, confirmé par un changelog récent : Subversion has been sunset
alors bon, je sais, tout le monde s'en fout et je suis un vieux con à utiliser subversion… c'est pas faux… et de fait je m'en fous aussi, je vais migrer mes repos et pis c'est tout
non, ce qui est particulièrement relou c'est que l'interface de github n'a pas changé, elle présente toujours la possibilité d'utiliser indifféremment git ou svn pour cloner ou checkouter (et justement je voulais checkouter) :
Use Git or checkout with SVN using the web URL.
au lieu de mettre un gros bandeau sur chaque page ou une alerte, ou un warning, ou une note, ou un quelque chose ! mais non, rien, absolument rien
bref la communication aurait été bien faite, j'aurais été préparé et je n'aurais pas été surpris, au lieu de ça je suis resté comme un (vieux) con, affligé devant mes erreurs de connexions incompréhensibles /rage
# Sans vouloir défendre Github (ou MS)
Posté par abbe_sayday . Évalué à 7.
Github a peut-être mal communiqué sur la fin du support de SVN, mais à en juger par les statistiques de StackOverflow, seuls 5% des développeurs affirmaient utiliser SVN. Parmi ceux-ci, seule une toute petite fraction l'utilisait avec Github.
Il n'y a pas que la maintenance qui a un coût, la communication aussi. Github a jugé bon de laisser les choses ainsi se terminer ; sans bandeau, sans message et sans crier gare (ce qui auraient coûté du fric en développement).
Nec spe, nec metu
[^] # Re: Sans vouloir défendre Github (ou MS)
Posté par barmic 🦦 . Évalué à 10.
Tu vivrais aussi bien qu'on dise pareil de Firefox ? C'est 2% des utilisateurs on s'en fout ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sans vouloir défendre Github (ou MS)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
0.02 % (le chiffre d’utilisation de SVN sur Github, donc celui qui nous intéresse ici), c’est 100 fois plus que 2 %. C’est donc pas le même genre de prise en compte.
Cela dit, Github aurait pu faire un effort et au moins enlever la mention de SVN dans l’interface – parce que ça, ils devront le faire un jour ou l’autre de toutes façons. Et mettre une phrase de notice que renvoie vers cette page par exemple, c’est pas ça qui coutait cher en développement.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Sans vouloir défendre Github (ou MS)
Posté par abbe_sayday . Évalué à 4.
Je m'y prépare malheureusement.
Après, on n'est pas dans le même contexte. La perte de Firefox serait une catastrophe pour le Web en entier. Firefox respecte les standards Web et la perte de ses parts de marché est due essentiellement à un abus de position dominante.
La périclitation de SVN c'est juste une évolution naturelle, Git - outil libre - a défoncé la concurrence libre et propriétaire, dont d'ailleurs Bitkeeper qu'il a remplacé pour la gestion du code source de Linux.
Nec spe, nec metu
[^] # Re: Sans vouloir défendre Github (ou MS)
Posté par barmic 🦦 . Évalué à 8.
C'est bien plus compliqué que ça. Il est difficile de trouver en quoi est-ce que blink ne respecte pas les standards du web et il existe des standards du web que Mozilla ne veut pas implémenter (l'autre jour quelqu'un parlait d'API autour de Bluetooth).
Ce n'est pas une question de standard du web, mais de diversité des approches. Si nous avions Chrome et Firefox à 50% chacun de part de marché nous ne nous baserions pas sur les standards du web, mais sur un sous ensemble qui est un consensus entre ce qu'implémente les deux navigateurs.
C'est donc tout l'inverse c'est la fragilité de la norme à la fois parce qu'il y a des choses dedans qui sont discutables et par crainte que le comité se fasse tordre le bras ou soit ignoré.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# 1 an
Posté par Psychofox (Mastodon) . Évalué à 6.
Ça avait été annoncé il y a un an et relayé dans moultes sites tech il me semble.
# Futur de Subversion
Posté par Marotte ⛧ . Évalué à 6. Dernière modification le 14 janvier 2024 à 01:29.
Que Github cesse de supporter svn ça me surprend pas des masses (Après tout dans "Github" il y a "Git"…). Mais je pense que si svn a clairement perdu son statut de CVS de prédilection des développeurs des logiciels libres, on ne doit pas pour autant considérer qu’il est devenu obsolète.
Car c’est ce que j’observe autour de moi, tout le monde pense que svn est obsolète. Or il me semble que le logiciel est encore activement développé. Et que même si git rend brillant le poil des mamans ours, svn conserve quelques avantages potentiellement utiles, à savoir : la centralisation, et surtout la possibilité de ne pas avoir à télécharger l’ensemble d’un dépôt pour faire une modification sur un ou quelque fichier.
Je m’interroge également sur Mercurial, qui était aussi me semble-t-il une option à considérer pour la gestion des sources.
Git a un peu « tué le game » comme disent les jeunes, mais l’une des forces du libre c’est la richesse de son écosystème. Pensez-vous que le paradigme de svn (et donc svn lui même), ou encore Mercurial, soit amené à disparaître dans un futur proche, ou bien au contraire conserveront-ils une petit base d’utilisateurs de 1, 3 ou 5 % d’aficionados ?
[^] # Re: Futur de Subversion
Posté par Marotte ⛧ . Évalué à 2.
Comme disent les vieux !
[^] # Re: Futur de Subversion
Posté par BAud (site web personnel) . Évalué à 1.
ah non ! les vioques parlent de djeuns ;-)
[^] # Re: Futur de Subversion
Posté par abriotde . Évalué à 3.
C'est à dire que tant que SVN conserve un avantage sur Git, il devrait continuer. En l'occurrence je ne vois que ne pas copier tout le repo. Mais bon Git à les sous-repo. L'intérêt reste limité. Reste surtout les bases de code non migrées. En informatique on à le cas Cobol.
[^] # Re: Futur de Subversion
Posté par ... a little wood elfe . Évalué à 2.
Quel est le soucis avec Cobol ? Là où je travaille cela fait plusieurs années que la possibilité de stocker le code cobol dans git est proposée aux équipes.
Dans mon équipe on a ainsi un million de lignes de code Cobol dans git et dans une instance privée de github avec un Sonar vérifiant la qualité du code à chaque PR.
[^] # Re: Futur de Subversion
Posté par abriotde . Évalué à 2.
Le soucis, ce n'est pas Cobol dans Git. C'est Cobol.
Il existe 100 fois mieux comme langage pour programmer efficacement. Le problème c'est que migrer un code Cobol vers un autre langage, cela demande du temps et de l'argent… Par contre, migrer de SVN à Git me semble assez simple.
[^] # Re: Futur de Subversion
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 14 janvier 2024 à 02:40.
Rien n'interdit d'utiliser Git de manière centralisée, c'est même courant.
Et surtout, Git évolue aussi et prends en compte les cas que tu décris, avec des outils comme https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/, https://github.blog/2021-11-10-make-your-monorepo-feel-small-with-gits-sparse-index/ ou https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ (billets Github mais ce sont bien des fonctionnalités Git).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Futur de Subversion
Posté par Renault (site web personnel) . Évalué à 8.
Surtout que les défauts de SVN sont quand même assez énormes à côté justement.
SVN était un bon outil à l'époque, mais le conserver reste un handicap surtout au sein d'une équipe de développement.
[^] # Re: Futur de Subversion
Posté par Victor STINNER (site web personnel) . Évalué à 4.
GitHub est quand très centralisé, même si techniquement Git gère plusieurs "upstreams", en pratique c'est très courant que tout soit fait un dépôt unique à base de pull requsts. Sans parler du projet GitHub centralisé avec ses tickets centralisés.
[^] # Re: Futur de Subversion
Posté par cosmocat . Évalué à 2. Dernière modification le 14 janvier 2024 à 20:39.
Oui mais tu fais assez souvent, quand tu contribues à des projets open-sources, du "multi-remotes" avec le dépôt upstream et ton fork (origin). Et dès fois également les dépôts d'autres contributeurs.
Pour un auquel je contribue, j'en ai par exemple souvent au moins 5.
[^] # Re: Futur de Subversion
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
J'ai vu des entreprises ou svn était utilisé pour gérer une base de documents (pas du code). En gros ça permettait de facilement synchroniser un dossier avec tous les documents sur son PC pour l'avoir sous la main, et de signaler (mais pas de résoudre) les conflits d'édition.
C'était utilisé par des gens pas forcément très techniques, via une interface graphique (tortoisesvn par exemple).
Au delà des fonctions manquantes dans git (par exemple: la possibilité de "verrouiller" un fichier pendant qu'on l'édite), le problème avec git serait surtout qu'il est trop compliqué: branches locales et distantes et plein d'autres concepts, qui en plas ne sont pas forcément bien exposés dans les interfaces graphiques. Ça ne marcherait donc pas du tout aussi bien dans cet usage.
[^] # Re: Futur de Subversion
Posté par barmic 🦦 . Évalué à 2.
Je vois pas en quoi le verrou est une bonne idée. Je comprends le principe théorique mais sorti de ça en pratique c'est un problème que les utilisateurs soient techniques ou pas.
Quant à faire utiliser un gestionnaire de version à des non techniques, ils doivent apprendre à commit, checkout et add (je pense que c'est le minimum) et ça demande déjà d'apprendre et d'avoir une bonne rigueur. Git sera bien pire, mais si les utilisateurs ne sont pas en mesure de résoudre des conflits grâce à svn, il vaut mieux utiliser un outil de synchronisation qui est fait pour qui gérera lui même les versions etc.
Je dis pas que svn doit mourir, s'il plaît pourquoi pas. Il me semble que les BSD utilisent CVS pour distribuer les sources des ports et pourquoi pas (pour parler d'un outil encore plus vieux considéré comme supplanté par svn).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Futur de Subversion
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 15 janvier 2024 à 19:25.
99% (statistique perso) des repos Git utilisent la centralisation : au coeur du process tu as 1 et 1 seul repo sous github, gitlab, git tout court… c'est quasi impossible de travailler sans.
L'outil Git n'est pas centralisé, mais les process le sont. Et changer de répo centralisé est trivial avec Git.
T'es pas obligé du tout :
git clone --depth 1En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Futur de Subversion
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
--depth permet de ne pas récupérer l'historique. Svn permet en plus de ne pas récupérer tous les dossiers du dépôt mais seulement une sous-arborsescence. Ce qui pourrait régler tous les débats sur les "monorepos contre submodules" dans git et les outils comme google repo pourgérer ces problématiques
[^] # Re: Futur de Subversion
Posté par barmic 🦦 . Évalué à 2.
Les solutions de Google, Microsoft et Facebook sont des cas très particulier et je ne suis pas certains que svn soit en mesure de les gérer sans développement en plus (en fait c'est même certain que le fait que toutes les opérations se fasse en appelant le serveur est un énorme problème pour eux).
Le mono ou multi repo est une question d'organisation et de philosophie/politique pas de technique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# usage ?
Posté par steph1978 . Évalué à 4.
Pour ma part je me retrouve dans
En gros je n'utilise SVN que pour récupérer un bout du repo GIT (commit en particulier, sous-dossier) sans avoir à passer par des dumps/extracts de tgz.
Et de ce que je comprends, si je me documente un peu, je peux le faire autrement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.