Développement : Versions revient avec une toute nouvelle version
Versions (99 €) est un client Subversion (SVN), outil de versionnement similaire à Git qui a perdu en popularité ces dernières années, mais qui reste utilisé par de nombreux développeurs. Cette app est arrivée sur macOS il y a près de 13 ans et elle n’avait pas évolué de manière importante depuis des années. Son changement de propriétaire en début d’année change la donne toutefois, puisque c’est une mise à jour majeure qui est désormais proposée.
La deuxième version de Versions adopte une interface modernisée et optimisée pour macOS Big Sur. Pour l’occasion, le mode sombre du système est pris en charge et la barre latérale adopte le nouveau module fourni par Apple, avec effet de translucidité. L’icône est aussi nouvelle, l’ancienne ne collait plus trop avec le style de Big Sur. Sur le plan de l’interface, plusieurs autres ajustements sont à noter, dont l’ajout d’icônes dans la liste de fichiers pour réaliser des actions.
L’autre gros morceau est la prise en charge des Mac Apple Silicon. Versions est désormais un binaire universel, optimisé tant pour les Mac Intel que pour les nouveaux modèles basés sur les puces d’Apple. Une mise à jour des dépendances a été effectuée dans la foulée et c’est notamment la dernière version de Subversion qui fait tourner l’app.
Même si Versions recommande d’utiliser macOS Big Sur, l’app est aussi compatible avec macOS 10.15. Une démo fonctionnelle pendant sept jours est proposée sur le site, la licence est ensuite vendue 99 € HT. Les utilisateurs de la version précédente peuvent passer à la nouvelle pour la moitié du prix.
Il faut dingue pour utiliser Subversion à ce jour ! 🤯
@dperetti
Pourquoi ?
N’étant pas développeur, votre réaction m’interpelle 😊
@stefhan
GIT lui est supérieur en presque tout point, beaucoup plus répandu (pour des projets récents bien sur), utilisé par la presque totalité des projets libre/académiques/linux, très répandu dans l'industrie, supporté par des services en lignes majeures comme GitHub et GitLab , intégré dans presque tous les IDE (dont Xcode) et éditeur texte dans le vent.
Git est distribué (c'est très pratique en cas de panne temporaire), SVN centralisé. Git permet à un développeur sans le serveur central, de partager des patchs à un autre développeur, parmi maintes possibilités.
Git gère beaucoup mieux les branches dans un projet que SVN: une branche référant des patchs, pas un autre dossier copié/dérivé du code source.
Linus Torvalds recommande Calg..heu utilise Git, fin de l'argumentaire ;)
Je pense aussi qu'il faut être dingue pour utiliser Subversion pour un _nouveau_ projet. (voir même un ancien, je dirais)
@oomu
Même sur les anciens projets j’utilisais git2svn rien que pour avoir les commits locaux …
@Ded77 pour des projets simples d'accord. pour les projets complexes ... c'est parfois une fameuse aventure...
https://gcc.gnu.org/wiki/GitConversion
@oomu
"GIT lui est supérieur en presque tout point"
N’exagèrerons rien, mais je suis flatté 🙃😉🥰😂
@oomu
"Linus Torvalds"
L’histoire de la naissance de Git est vraiment intéressante 😋
@oomu
Un éclairage plus nuancé: https://svnvsgit.com/#:~:text=%20Subversion%20vs.%20Git%3A%20Myths%20and%20Facts%20,when%20you%20merge%20two%20branches%20in...%20More%20
@stefhan
Gérer un projet de dev sans système de versioning c’est devenu impensable. Surtout si on est plus de 1 à bosser dessus (mais bon, même pour mes sites web perso où je suis tout seul je fais du versioning). SVN (Subvertion) était LA solution il y a 15 ou 20 ans. J’ai bossé sur pas mal de projets avec SVN et du coup j’utilisais ce logiciel (Version) super bien foutu…
Et puis GIT est arrivé. Il a quelques inconvénients, mais ces avantages ont très vite fait qu’il a supplanté SVN pour faire du versioning… Du coup, SVN est devenu has been, surtout auprès des jeunes développeurs. Reste que j’ai rencontré 2 ou 3 devs (anciens…) qui préfèrent SVN et surtout qu’il a le Legacy (le vieux code) qui peut être resté sur cette techno… J’ai d’ailleurs été emm…dé il y a 3 ans quand on m’a refilé un petit projet SVN qu’il fallait traiter très rapidement : je n’avais plus Version et cela me faisait suer de racheter une licence pour ça. Je suis donc parti sur un soft gratuit et j’ai pleuré…
La pire des choses avec Subversion, c'est qu'il incorpore des dossiers .svn dans tous les dossiers et sous-dossiers du projet.
Si par malheur un de ces dossiers est effacé ou bidouillé, c'est le bazar assuré.
Indépendamment de cela, git est tellement infiniment supérieur et tous points et tellement devenu le standard absolu...
(Pour la petite histoire, c'est moi qui avais écrit ce que je crois avoir été le tout premier client svn pour mac, svnX ☺️).
il n'y a qu'un dossier .svn, il est à la racine du projet, il n'y en pas pas dans les sous-dossiers.
Et un grand merci pour svnX, je m'en sers toujours ^^
@westindies972
> il n'y a qu'un dossier .svn
A partir de SVN 1.7.
Avant, y'a bien un dossier .svn dans chaque dossiers et sous-dossiers etc du projet.
En son temps, j'ai adoré SVN, mais jamais je me suis surpris à songer une seule fois à revenir en arrière depuis que j'utilise Git, ce qui est de facto une preuve de supériorité en tout point.
@dperetti C'est clair que j'aurais du mal à me passer de mon workflow git aujourd'hui
@dperetti
"Il faut dingue pour utiliser Subversion à ce jour ! 🤯"
Ou aimer souffrir 😂
Et migrer un projet SVN vers Git n’a rien de sorcier, on peut même garder les auteurs des commits. Ça se fait très bien :)
Voir ma réponse à votre commentaire précédent ... ( pareil pour KDE ils ont ramé sur le sable pendant un bon moment !)
Je ne doute pas de la qualité du logiciel mais je préfère mettre l’argent dans ma licence IntelliJ qui apporte pleins de fonctionnalités!
Autant de budget pour SVN? J’imagine qu’il doit exister des plugins gratuits pour VsCode ou IntelliJ! J’imagine aussi qu’il y a un besoin pour certains développeurs … sinon ce soft n’existerait pas…
la différence principale entre SVN et Git si je ne m’abuse est le côté centralisé du repo (la source de vérité) dans le cas de SVN alors que Git est bien plus flexible et que limite chaque dev peut posséder l’intégralité du code (donc plus rassurant).
On utilise souvent Git avec un seul repo « origin » remote comme SVN avec une vision centralisée…
Perso, bien que vieux, je préfère Git aussi. Et pleins de littérature autour. C’est vrai que ce genre d’outil est indispensable pour un travail en équipe.
J’aurais même envie de l’utiliser pour mes documents perso de la vie de tous les jours (autres que le code) quand je le maîtriserai mieux …
D’après les anciens (plus que moi), le mieux pour maîtriser ce genre d’outils est de faire le maximum d’opérations au moyen de lignes de commande dans un Shell. Du coup, encore un point en moins pour utiliser le logiciel présenté, non?
@deodorant
"D’après les anciens (plus que moi), le mieux pour maîtriser ce genre d’outils est de faire le maximum d’opérations au moyen de lignes de commande dans un Shell."
Même pour Git le Shell reste un outil de choix 🥸
@deodorant
question de préférence. y a de très bon ide ou outil graphiques dédiés pour GIT. et dans le même temps utiliser git dans un terminal linux est très puissant et plaisant aussi.
chacun ses approches.
et oui, RIEN n'empêche d'utiliser GIT pour autre chose que du code source, y a de nombreux usages variés avec.
Git est vraiment très très compliqué. Je pense pas avoir autant galéré avec n’importe quel autre outil informatique. Encore maintenant après plusieurs années d’expérience y’a plein de fonctionnalités que je ne comprends pas ou ne sait pas utiliser. Je trouve quand même Linus bien tordu dans sa tête. Donc je comprends les vieux de la vieille qui n’ont pas eu le courage de passer sur cette usine a gaz.
@l3chvck
"Je trouve quand même Linus bien tordu dans sa tête. Donc je comprends les vieux de la vieille qui n’ont pas eu le courage de passer sur cette usine a gaz."
Les vieux de la vieille détestent en général SVN qui n’a jamais été qu’un pis-aller.
Et s’il te semble plus simple que Git c’est une vision très superficielle.
Étrange que tu ais tant de difficultés avec Git quand même, c’est une construction assez logique même s’il y a quelques concepts un rien abstraits.
@l3chvck
"Je trouve quand même Linus bien tordu dans sa tête."
Un beau Git 😂😂😂
@l3chvck
amusant, j'ai trouvé git très simple.
certes, les concepts de "rebasing" peuvent être un peu compliqué à saisir, mais l'outil git lui même a une syntaxe claire, est très explicite (il donne des explications) et est hyper-documenté sur internet avec 15 gazillions de tutoriels en toute langue et quasi tout ingénieur développement qui le connait et prêt à former...
bref, Linus me parait des plus raisonné comme personne.
@l3chvck
> Je pense pas avoir autant galéré avec n’importe quel autre outil informatique
Oh, heureux celui qui n'a jamais eu à se coltiner la commande en ligne de Clearcase...
J’ai pas mal utilisé Subversion pour gérer des contenus bureautiques (Word, Excel, des bitmaps) et, sauf erreur de ma part, il gère des deltas de binaires, ce que Git ne fait pas. 90 versions d’un binaire de 30Mo pesaient 60 Mo, de mémoire.
Bien interfacé, TortoiseSVN lance Word pour faire les diff, c’est un bonheur.
Dommage qu’il n’y ait pas de client Tortoise sur Mac, à la connaissance.
@DahuLArthropode
> sauf erreur de ma part, il gère des deltas de binaires
git aussi. Mais comme la plupart des formats binaires sont également compressés, la moindre modification génère un contenu très fortement différent, et la deltatification est alors peu efficace et génère des coûts et des lourdeurs de stockage importants.
> 90 versions d’un binaire de 30Mo pesaient 60 Mo, de mémoire.
Ce qui démontre bien qu'il fait des deltas, sinon vous auriez observé 90*30Mo = 270Mo, pas 60..
Si c'est pour gérer que des objets binaires opaques type "documents", pas "texte", un SharePoint, Dropbox, pCloud ou même Google Drive qui proposent tous de gerer les versions de trucs opaques fait l'affaire tout autant.
Parce qu'avec des binaires, le merge, la gestion des merges conflicts, les diffs, le cherry picking, tout cela n'est plus possible, et tout modification à plusieurs ne peut que se faire de manière séquentielle.
Mais selon le volume de documents et la fréquence de leur modification, git peut très bien faire la même chose que svn. Et TortoiseGit doit pouvoir être configuré tout comme TortoiseSVN pour lancer Word pour faire les diffs.
> Dommage qu’il n’y ait pas de client Tortoise sur Mac, à la connaissance.
Les outils Tortoise s'appuient tous sur l'API d'extension de l'explorateur de fichiers de Windows. Donc, non, y'aura jamais de version TortoiseX pour Mac.
@byte_order
"SharePoint, Dropbox, pCloud ou même Google Drive qui proposent tous de gerer les versions de trucs opaques fait l'affaire tout autant. "
Pas si on veut étiqueter des ensembles cohérents de fichiers (en bureautique aussi, il y a des dépendances), si on veut distinguer des versions intermédiaires de versions livrées, si on veut tracer les modifications effectuées, etc. Les solutions d’archivage gèrent des versions, mais ne font pas de gestion de configuration.