L'équipe principale de FreeBSD nomme un groupe de travail pour explorer la transition de Subversion vers Git

Version imprimable

03/09/2019, 13h01
Bill Fassinou

1 pièce(s) jointe(s)

L'équipe principale de FreeBSD nomme un groupe de travail pour explorer la transition de Subversion vers Git

L'équipe principale de FreeBSD met en place un groupe de travail pour explorer la transition de Subversion vers Git,
l’équipe rencontre-t-elle des difficultés avec Subversion ?

La fondation FreeBSD, qui s’occupe du développement de FreeBSD, a publié récemment son deuxième rapport trimestriel montrant l’évolution du système d’exploitation libre. Dans ce rapport, qui clôture le second trimestre de l’année 2019 pour ses développeurs, la fondation a annoncé que l’équipe principale de développement de FreeBSD a voté oui pour explorer la transition du code source du système d’exploitation de Subversion (SVN) vers Git. Pour cela, l’équipe formera un groupe de travail qui sera dirigé par Ed Maste, directeur de projet au sein de la fondation.

FreeBSD est un système d'exploitation avancé pour les plateformes modernes de type serveur, station de travail et système embarqué. L’OS propose des fonctionnalités réseau avancées, une sécurité poussée et des performances de haut niveau. FreeBSD est utilisé par certains des sites Web les plus visités ainsi que par la plupart des systèmes embarqués orientés réseau et des systèmes de stockage les plus répandus. De nombreux fournisseurs d’appliances virtuelles de haut niveau fondent leurs produits sur le système d’exploitation FreeBSD.

En 2016, cela a même poussé Microsoft à faire fonctionner FreeBSD sur Hyper-V, la plateforme de virtualisation pour Azure. Ce qui a permis à l'entreprise d'assurer un support et un SLA d'entreprise à ses clients exécutant l'image de FreeBSD dans Azure. Vieux de 25 ans, le système d’exploitation FreeBSD est actuellement à sa version 12.0 (version de production), avec une version 12.1 en développement. Depuis juillet 2012, FreeBSD utilise Subversion en tant que seul système de contrôle de version pour stocker tout le code source de FreeBSD.

Pièce jointe 501050

D’après sa documentation, une version allégée de Subversion est déjà installée sur FreeBSD en tant que « svnlite ». La seule différence par rapport à l'utilisation normale de Subversion est que le nom de la commande est « svnlite ». Cependant, l’équipe principale de développement de FreeBSD a annoncé dans le rapport clôturant les travaux du deuxième trimestre qu’elle veut effectuer la transition vers Git.

Pourquoi l’équipe a-t-elle choisi de faire cette transition ? Le rapport ne mentionne pas de raison particulière, mais laisse paraître que Git jouera probablement un rôle très important dans le projet FreeBSD. Pour certains, la raison de cette transition est très simple. Ils estiment que Git est de loin un meilleur logiciel de gestion de versions que Subversion, et ce, sur tous les plans. Pour d’autres, Git est soutenu par une grande communauté d’utilisateurs ce qui forme en soi un avantage majeur.

« Je n'ai aucun problème avec Git ou CVS (Current Versions System, un autre système de gestion de version créé en 1990 par CVS Team), mais Subversion combine le pire des deux mondes. Il y a trop de problèmes avec Subversion pour mentionner quelque chose en particulier. C'est un mauvais outil pour presque tous les cas d'utilisation », a déclaré l’un d’eux. En effet, Subversion est un logiciel de gestion de versions, distribué sous licence Apache. Il a été conçu pour remplacer CVS. En 2010, SVN est devenu officiellement un projet de la fondation Apache, prenant le nom d'Apache Subversion.

Ses auteurs s'appuient volontairement sur les mêmes concepts et considèrent que le modèle de CVS est bon. Pour les auteurs de Subversion, CVS dispose déjà d’un modèle très bien conçu donc seule son implémentation est perfectible ou susceptible d’être améliorée. Git, quant à lui, est un système de versionning (système de gestion de version) décentralisé. C'est un logiciel libre créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale GNU version 2. Il existe un dépôt dans lequel tous les changements sont incorporés et qui permet aux utilisateurs d’y télécharger leurs propres copies de travail.

Les utilisateurs disposent également d’un dépôt complet qui comprend l’historique local sans qu’ils aient besoin d’une connexion permanente au réseau. Ainsi, contrairement à Git, Subversion est un système de gestion de versions centralisé et seul le dépôt contient le journal complet des modifications de données, les copies de travail ne contiennent que la version la plus récente. Selon certains, Subversion a voulu se positionner comme un simple système de gestion de versions client-serveur, mais il est passé à côté.

Ils estiment que Mercurial (un autre logiciel de gestion de versions) est encore meilleur que Subversion sur cet aspect. Pour eux, il est logique que FreeBSD, qui est un système d’exploitation parmi les plus utilisés sur les architectures serveur, songe à quitter Subversion. « Git va sans doute leur permettre d’être plus productif et plus compétitif à l’avenir », ont-ils déclaré. Toutefois, notons que l’équipe principale de développement de FreeBSD n’a pas clairement évoqué la raison de cette transition, mais ils espèrent en tirer un avantage.

Source : FreeBSD

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Quel logiciel de gestion de versions utilisez-vous et pourquoi ?
:fleche: L'équipe de FreeBSD a-t-elle raison de vouloir migrer de Subversion vers Git selon vous ?

Voir aussi

:fleche: Microsoft lance sa propre version de FreeBSD, afin d'assurer un support et un SLA d'entreprise à ses clients exécutant l'image de FreeBSD dans Azure

:fleche: De nouvelles vulnérabilités découvertes sur les systèmes Linux et FreeBSD permettant aux pirates d'avoir un contrôle à distance

:fleche: Red Hat découvre trois vulnérabilités dans le noyau Linux qui pourraient nuire aux systèmes Linux par une attaque du ping de la mort
03/09/2019, 13h13
L33tige

C'est bien vrai, pour travailler régulièrement avec le simple fait qu'une branche sur SVN == un dossier c'est une horreur quand on est sur plein de projets et qu'on crée pleins de branches, avec GIT, une branche c'est juste une suite de commits, donc un seul dépôt local pour plusieurs branches.
03/09/2019, 14h12
Jbx 2.0b

Mais non svn c'est génial ! :roll:

Au moment ou j'ouvre ce post, sur mon pc...

Citation:

CMake Error at cmake/ThirdParty/XXXX.cmake:318 (message):
Unable to find 'release-shared' for boost-1.63.0 (error: svn: E155004: Run
'svn cleanup' to remove locks (type 'svn help cleanup' for details)
03/09/2019, 14h37
Zefling

Citation:

Envoyé par Jbx 2.0b

Mais non svn c'est génial ! :roll:

Ouais trop génial !

Tellement génial qu'en mettant à jour SVN j'ai pété mon repo. Seulement moyen de récupérer mon code : svn2git .:whistle:
03/09/2019, 16h21
grunk

Pour moi les 2 forces de Git par rapport à SVN c'est :
- sa gestion des branches
- tous les outils qui gravitent autour (github, gitlab).

La décentralisation c'est le truc dont tlm parle mais je suis pas certains que beaucoup l'utilise réellement en dehors de leur dépôt local.
J'ai jamais été chercher une branche sur le pc d'un collègue par exemple , si besoin on pousse la branche sur le serveur , c'est plus simple.
03/09/2019, 17h36
Steinvikel

Petite précision sur la licence Git, c'est pas juste GNU version 2, mais GNU GPL version 2 ...une licence plus stricte en terme de "libre" que ne l'est la GNU LGPL version 2.
04/09/2019, 16h47
esperanto

Citation:

Envoyé par grunk

La décentralisation c'est le truc dont tlm parle mais je suis pas certains que beaucoup l'utilise réellement en dehors de leur dépôt local.
J'ai jamais été chercher une branche sur le pc d'un collègue par exemple , si besoin on pousse la branche sur le serveur , c'est plus simple.

Sauf que, justement, dans le monde du libre, n'importe qui n'a pas le droit de pousser sa branche sur le dépôt principal du projet.
Et depuis l'avènement des GitHub/GitLab et autres, la méthode pour contribuer à un projet, c'est : créer un clone sur GitHub ou GitLab, puis un clone de celui-ci en local, ensuite tu déposes tes modifs sur ton clone serveur et tu lances un pull request
Donc, même si tu centralises en partie avec GitHub/GitLab, il n'en reste pas moins que tu manipules au moins deux dépôts côté serveur en même temps (le tien et le principal), ce que CVS et SVN ne permettent pas de faire. Difficile de comprendre comment ils ont pu faire sans aussi longtemps.
04/09/2019, 17h05
champomy62

Citation:

Envoyé par esperanto

Sauf que, justement, dans le monde du libre, n'importe qui n'a pas le droit de pousser sa branche sur le dépôt principal du projet.
Et depuis l'avènement des GitHub/GitLab et autres, la méthode pour contribuer à un projet, c'est : créer un clone sur GitHub ou GitLab, puis un clone de celui-ci en local, ensuite tu déposes tes modifs sur ton clone serveur et tu lances un pull request
Donc, même si tu centralises en partie avec GitHub/GitLab, il n'en reste pas moins que tu manipules au moins deux dépôts côté serveur en même temps (le tien et le principal), ce que CVS et SVN ne permettent pas de faire. Difficile de comprendre comment ils ont pu faire sans aussi longtemps.

Des patchs ?
05/09/2019, 10h30
Zefling

Citation:

Envoyé par champomy62

Des patchs ?

Ouais, les patchs, et je dois dire que je ne regrette pas cette époque. :aie:
05/09/2019, 20h08
floyer

Citation:

Envoyé par Steinvikel

Petite précision sur la licence Git, c'est pas juste GNU version 2, mais GNU GPL version 2 ...une licence plus stricte en terme de "libre" que ne l'est la GNU LGPL version 2.

La LGPL a été faite typiquement pour des bibliothèques (bien que le L soit pour Lesser et non Library). Elle permet d’utiliser une bibliothèque dans un produit propriétaire, seules les modifications de la bibliothèque même sont à fournir avec les sources.

Tant que l’on ne fait pas d’édition de lien entre git (ou une version modifiée), GPL et LGPL sont équivalent.
05/09/2019, 20h17
floyer

Citation:

Envoyé par grunk

La décentralisation c'est le truc dont tlm parle mais je suis pas certains que beaucoup l'utilise réellement en dehors de leur dépôt local.
J'ai jamais été chercher une branche sur le pc d'un collègue par exemple , si besoin on pousse la branche sur le serveur , c'est plus simple.

Si j’ai besoin de contribuer au développement d’un logiciel (Linux, FreeBSD...), avec SVN, il me faut envoyer un patch à une personne qui a les droits, ou demander des droits. Avec GIT, je fait un commit sur mon dépôt et en fait part à la personne qui a des droits sur le développement. C’est plus fiable qu’avec les patchs, car si les versions diffère, cela se gèrera (merge), ou se verra (conflit lors du merge).

Par ailleurs, même si cela ne sert que pour permettre le dépôt local, gérer des merge avec son développement local... , cela peut être intéressant.
05/09/2019, 23h34
Steinvikel

Citation:

Envoyé par floyer

Elle permet d’utiliser une bibliothèque dans un produit propriétaire, seules les modifications de la bibliothèque même sont à fournir avec les sources.
Tant que l’on ne fait pas d’édition de lien entre git (ou une version modifiée), GPL et LGPL sont équivalent.

Oui, les licences GNU ont été pensées à la base pour le développement logiciel, mais malgré tout se voulaient également polyvalente (bien que pas toujours adapté).

La licence GNU GPL a vu le jour pour combattre l'environnement vérolé par les pratiques économiques, afin de garantir un environnement sain, où les dérives constatés ne peuvent avoir lieu. C'est le but du "copyleft" de la GPL, c'est à dire : les interdictions qu'elle énumère, de garantir un maximum de libertés coté utilisateur final. La LGPL est moins restrictive, elle interdit moins de choses, ce qui se traduit par moins de libertés garanties pour l'utilisateur final, et une ouverture à de possibles dérives (bien que contenues).
Pour être un peu plus généraliste, la principale différence que présente la LGPL, c'est qu'elle ne présente plus la viralité de la GPL (obligation, pour tout produit intégrant une solution couvert par une licence GPL, d'être lui-aussi publié sous licence GPL).

Si dans la pratique les deux paraissent équivalent, leurs répercutions dans la société les différencient clairement. Si l'on choisi de publier sous licence libre pour répondre à des problèmes éthiques, cette différence est d'envergure, car impactant indirectement sur des libertés de la vie de tout les jours. C'est en ce sens que je désignait la GNU LGPL comme étant moins stricte en terme de "libre". D'ailleur, quand l'on regarde de plus près les mécanisme de conversion /changement de licences GNU, on s'aperçoit rapidement qu'il n'est possible de changer que pour une licence à plus fort copyleft. --> LGPLv2 vers LGPLv3, mais v3 vers v2 impossible ...LGPL vers GPL, mais dans l'autre sens, impossible.