Liens connexes

Dépêche modérée par

: Arch: un programme de gestion de version prometteur.

Posté par Edouard Gomez (page perso, ). Modéré le 09 juillet 2003.
0
Dans le monde du Logiciel Libre, CVS/RCS est un outil qui a su se rendre indispensable pour gérer le travail collaboratif de plusieurs développeurs en parallèle. Cependant, ce logiciel montre bien vite ses limites quand il s'agit de développements distribués et fortement axés sur l'usage de branches.

Des alternatives pointent le bout de leur nez, une des plus prometteuses: Arch. Elle résout bon nombre de problèmes inhérents à CVS/RCS et surpasse déjà Subversion en termes de fonctionnalités.

> Lire la suite (104 commentaires, moyenne: 2,2).   [dépêche : 4468 caractères]

L'utilisation d'outils de versionning est une des clefs de la réussite du développement des Logiciels Libres. Ils permettent tout simplement aux divers développeurs de collaborer en leur facilitant le partage et la mise en commun de contributions.

Aujourd'hui, l'outil le plus répandu est CVS (Concurrent Versions System). On le trouve presque partout, la plupart des plates-formes d'hébergement de projets libres offrent un hébergement de repository CVS (Sourceforge, Savannah pour ne citer qu'eux). Malheureusement, CVS est basé sur RCS (Revision Control System) et hérite de toutes ses erreurs de conception. Trois problèmes majeurs ressortent du lot (la liste pourrait être beaucoup plus longue):
- CVS se base sur le versionning par fichier. Cela interdit les commits dits atomiques ("tout ou rien"). On peut vite se retrouver avec un arbre de sources dans un état incertain pour peu que d'autres développeurs aient crée des situations de conflits.
- CVS ne possède que la notion de fichier... les notions de répertoire, de lien symbolique, de metadata telle que les permissions de fichier lui sont totalement inconnues. Le rennomage d'un fichier est d'ailleurs impossible sous peine de perdre son historique, or, l'intérêt d'un outil de versionning, c'est bien de tracer l'historique des fichiers.
- CVS est un outil profondément centralisé. Le travail des développeurs se fait sur un seul et unique repository de sources dont chacun possède un snapshot de travail. Ce dernier point est celui qui représente le plus grand inconvénient (branches coûteuses et inadaptées, problèmes d'administration... j'en passe et des meilleures).

Ces trois points constituent une bonne part des raisons qui ont poussé Linus Torvalds à se tourner vers un outil propriétaire nommé BitKeeper pour le développement du noyau Linux 2.5. En effet, CVS ne satisfaisait pas le besoin de développement décentralisé du noyau, où chaque hackeur majeur possède sa propre branche et fournit les patchs à Linus pour une admission dans la ligne de développement principale. En 2002, lorsque Linus a cherché un outil libre répondant à ses besoins, le constat était sévère: il n'y en avait simplement pas.

On peut maintenant, après plus d'un an se demander où en sont les choses. Et bien, aussi étonnant que cela puisse paraître, les choses ont peu bougés. Le projet Subversion qui vise à remplacer CVS fait du sur place. Son principal atout est sa ressemblance avec CVS. Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS. A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.

Moi même intéressé par l'adoption d'un nouvel outil pour mes projets Libres, je suis tombé par hasard sur le projet Arch. A l'époque (Janvier 2003), la seule implémentation d'Arch (programme nommé "larch") était écrite en langage Shell (oui, oui ! à coup de sed, awk et autres programmes shell), bien sûr c'était très (très) lent mais cette implémentation servait surtout à valider les concepts sur lesquels se basait Arch. En voici certains, la liste n'est pas exhaustive:
- Arch se base sur les principes reconnus du "KISS" (Keep It Simple Stupid )
- Arch est orienté patchset. Les commits sont donc atomiques.
- Arch possède les notions de fichier, de lien symbolique, de répertoire et de metadata (permissions d'un fichier). Les rennomages de fichiers/répertoires ne sont plus un problème.
- Les archives Arch peuvent être partagées via les protocoles FTP, SFTP, Plain HTTP et WebDAV.
- Dans Arch, les branches ont un coût constant indépendant du nombre de fichiers du projet.
- Arch est profondément orienté "développement distribué". Rien n'est plus simple que de créer une branche locale de développement pour effectuer ses changements puis de les intégrer ensuite à la branche principale de développement.

Après une longue période d'inactivité de presque un an, son auteur principal, Thomas Lord, s'est mis à coder Arch en C (programme nommé "tla"). Le seul gros inconvénient d'Arch, sa lenteur, n'est plus aujourd'hui qu'un lointain souvenir. Déjà conquis par "larch" en terme de fonctionnalités, "tla" a tout simplement rendu Arch réellement utilisable dans des projets de toute échelle.

Il ne vous reste plus qu'à le tester. Un tutorial assez bien fait vous attends dans les liens afin d'en apprendre les bases et qui sait, peut être de l'apprécier...

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Re: Arch: un programme de gestion de version prometteur.

Posté par tuan kuranes (page perso, ) le 09/07/2003 à 06:34. (lien). Évalué à 18.

Pour mieux gauger :

Comparaison CVS, Meta-CVS, arch, Subversion, DARCS, OpenCM, monotone, Codeville,

http://zooko.com/revision_control_quick_ref.html(...)

ComparaisonSubversion and Meta-CVS :
http://users.footprints.net/~kaz/mcvs-svn-comparison.html(...)

Par l'auteur d'arch
Comparaison arch - bitkeeper :

http://www.fifthvision.net/open/bin/view/Arch/BitKeeper(...)

Comparaison arch - subversion :
http://www.fifthvision.net/open/bin/view/Arch/SubVersionAndCvsCompa(...)

KISS ???

Posté par Rozé Etienne () le 09/07/2003 à 06:55. (lien). Évalué à 3.

> - Arch se base sur les principes reconnus du "KISS" (Keep It Stupid Simple)

Cela doit être super bien mais qu'est-ce que c'est ?

Re: Arch: un programme de gestion de version prometteur.

Posté par Wajsberg Julien () le 09/07/2003 à 07:59. (lien). Évalué à 1.

Je suis bien intéressé par DARCS personnellement, surtout parce qu'il est fait en Haskell avec une théorie des patchs basée sur la physique quantique derrière :o)

Quelqu'un y a déjà touché et peut dire ses impressions ?

Re: Arch: un programme de gestion de version prometteur.

Posté par patatorz (page perso, ) le 09/07/2003 à 08:10. (lien). Évalué à 1.

C'est vrai que le pb de la gestion des branches dans cvs mériterait une évolution.
L'autre fonctionnalité qui mériterait d'être retouchée est le "check-out reserved", qui gagnerait a être pouvoir utilisé plus facillement, un peu a la clear-case.
A part ca, CVS c'est vraiment bien !

Re: Arch: un programme de gestion de version prometteur.

Posté par Rolland Dudemaine () le 09/07/2003 à 08:14. (lien). Évalué à 2.

- Dans Arch, les branches ont un coût constant indépendant du nombre de fichiers du projet.

Faut-il comprendre que le cout varie en fonctions du nombre de revisions/patches ?

Dans ce cas c'est mal, non ?

Sinon ca parait interessant, y'a-t-il deja des projets qui l'utilisent ?

Re: Arch: un programme de gestion de version prometteur.

Posté par romain () le 09/07/2003 à 08:19. (lien). Évalué à 1.

J'avais jeté un oeil sur différentes alternatives il y a un an, et Arch m'avait semblé intéressant, mais la documentation auteur semblait assez obscur. Le tutoriel est déjà un grand pas.

J'avais opté pour Subversion à l'époque ; je ne suis pas tout à fait de l'avis du post considérant subversion comme plus compliqué que CVS, la doc fourni avec étant plutôt très bien faite, même pour un novice.

Le gros avantage que je vois à Subversion, c'est sa portabilité ; associé à des outils graphiques tels que Tortoise, c'est pas le bonheur, mais presque, pour tous les développeurs.

Quelqu'un sait-il si il y a un port win32 de prévu pour Arch, d'une façon ou d'une autre ? (dans un package complet, pas via cygwin).

À votre bon coeur

Posté par Boa Treize (page perso, ) le 09/07/2003 à 08:50. (lien). Évalué à 11.

Ça fait un petit choc de lire le tutoriel, d'être dans un bon trip technique, et de se voir soudain rappeler à une réalité plus sombre. L'auteur d'arch est au chomage depuis plus d'un an, il a épuisé toutes ses réserves d'argent et il est surendetté.

http://regexps.srparish.net/tutorial-tla/little-help.html(...)

[+] Cette news c'est une merde !

Posté par ptit_tux () le 09/07/2003 à 10:22. (lien). Évalué à -2.

> Le projet Subversion qui vise à remplacer CVS fait du sur place.

N'importe quoi.
Regardes ici :
http://subversion.tigris.org/servlets/SummarizeList?listName=svn(...)

Cette mailing stocke les commits de subversion. globalement le rythme n'a pas changé.

Subversion est en phase beta. C'est pas la bonne période pour faire des inovations. De plus Subversion est de plus en plus utilisé et ce n'est pas non plus de moment de tout casser. L'objectif c'est la version 1.0 puis les inovations seront de retour.

NON et NON et NON subversion ne fait pas du sur place.

> Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS.

Excuse moi mon cher Edouard Gomez, mais tu es un con. Si tu t'étais renseigné 2 secondes tu aurais vu que ce que tu apprécies sur arch, existe sur subversion :
- les commits sont atomiques. C'est du versionnage de branche et non uniquement de fichier
- subversion ne se limite pas au fichier, il reconnait aussi les repertoire, tu peux les renommers, etc... Par contre la gestion des liens symboliques sera pour après version 1.0.
- Dans subversion il y a aussi la copie à coût 0 (la création d'une branche étant une copie).
- Lorsque tu développes avec subversion, tu as un dépôt local où tu fais toutes tes opérations. Après du peut faire un commit vers le serveur.
- Subversion, le backend, est orienté base de données. Actuellement il utilise Berkeley DB mais après la version 1.0 d'autre base de donnée seront supporté (mysql/postgresql, etc).
- Subversion consomme peut de réseau. Seul les diffs circulent et en compressé.
- Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.
- Subversion est très portable et basé sur la lib apr d'apache. Ainsi, Subversion tourne déjà pratiquement partout (Linux, Unix, Windows, Mac).
- Le protocol réseau de Subversion est parfaitement standard puisque c'est webDav. Tout client Dav peut fouiller un dépôt Subversion. Pour le serveur, Apache est utilisé (+ module dav + module subversion). C'est une garanti d'efficacité et de sécurité. C'est donc très facilement qu'https est dispo.
- etc

C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.

> A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.

100 % pure troll.

Le point fort de arch par rapport à subversion est son modèle plus distribué. Subversion restant sur un modèle plus centralisé. Cependant, l'objectif premier de subversion est TOUS les developpeurs et non seulement les développeurs de Linux. Quoiqu'il en soit, les devs de Linux ne sont pas oubliés. Un nouveau format de patch existe et permet de s'échanger des patchs qui contient des infos sur le renommage de fichier, déplacement des répertoires, changement d'attribut (les meta-donné) etc... Donc il n'y a pas de problème, a moyen terme ,pour la version 1.2 ou 2.0, les developpements distribués ne sont pas oubliés. Les fonctionnalités 1.0 sont déjà suffisante pour la faire (faire un "appliqué les différence entre la version 100 et 242 du dépôt d'Alan Cox sur mon dépôt local (avec renommage, meta-data, etc)" par exemple).

C'est news c'est de la MERDE.

PS : NRV.

Première impression

Posté par or zax () le 09/07/2003 à 15:13. (lien). Évalué à 3.

Je viens d'imprimer la documentation et d'achever la compilation. Dans mon cas je ne connais CVS que de nom, Subversion la même chose.

Je suis un ignorant dans les systèmes de gestions de versions. C'est donc en ignorant que je donne mes premières impressions sur Arch, ... franchement c'est sympas. Le tutorial est pas mal fait.

Donc pour ceux qui ont en horreur l'installation des usines à gaz qui donnent mal à la tête rien que d'y penser, l'installation et la prise en main de arch est vraiment accessible.

Il ne me reste plus qu'à essayer Subversion, car vue les controverses qu'il génère ici il doit être bien sympathique.

Par contre est-ce que quelqu'un à déjà mis en place ce genre de système dans de petites structures de développement d'intranet de gestion ?

Je travaille dans une structure où les développeurs sont minoritaires et les graphistes majoritaires.

Vous avez une idée pour mettre en place une procédure de production qui utiliserai Subversion ou Arch accessible à des graphistes ?

zax

Mmm, du bon tarball tout frais

Posté par Boa Treize (page perso, ) le 09/07/2003 à 21:38. (lien). Évalué à 1.

Marrant, tla (l'implémentation en C de Arch) est sorti en version 1.0.6 ajourd'hui. :)

Re: Arch: un programme de gestion de version prometteur.

Posté par Anthony Rabine (page perso, ) le 10/07/2003 à 07:31. (lien). Évalué à 2.

Personne n'a parle de ClearCase ici, qui est je pense un des meilleurs logiciels de gestion de versions (il comble les defauts enumeres dans l'article). Il est profondement encre au systeme Unix mais il existe des interfaces sous Windows. ClearCase est utilise a grande echelle dans mon entreprise et c'est un veritable bonheur a utiliser. Les commandes sont simples, efficaces, il existe de nombreux utilitaires ( pour representer les arbres de maniere graphique par exemple). Bref, un logiciel dont devraitent s'inspirer bon nombre de projets libres (depuis que je connais ClearCase j'ai du mal a utiliser CVS, il est trop limite).