Mais, qu'est-ce que subversion ?
C'est un logiciel de gestion de version, un système permettant de maintenir plusieurs versions d'un même fichier et d'en retenir l'historique (voir la définition wikipédia dans les liens).
Le système de gestion de fichier le plus connu est CVS (Concurrent Versioning System)
Pourquoi remplacer CVS ?
Bien qu'étant l'un des système de gestion de version les plus utilisés, CVS a quelques fonctionnalités qui font défaut... C'est pourquoi de nouveaux projets tel subversion sont né.
Qu'apporte subversion de plus par rapport à CVS ?
- Gestion des répertoires.
- Possibilité de renommer et déplacer des fichiers.
- Ajout de méta-données sur les fichiers et historique de celles-ci.
- Possibilité d'utilisation d'Apache comme serveur et de WebDAV /DeltaV comme protocole.
- Optimisation de l'utilisation de la bande passante
- Gestion simplifiée des fichiers binaires
En bref, plein de bonnes choses à essayer; la version 1.0 est proche et je ne peux que vous conseiller de tester... vous serez vite conquis.
Aller plus loin
- Subversion (2 clics)
- Status (1 clic)
- Download (3 clics)
- Définition (3 clics)
- CVS (2 clics)
# Re: Subversion RC-1
Posté par patatorz . Évalué à 4.
Il sait aussi gérer les fichiers binaires, mais c'est vrai que c'était qqchose de perfectible (suffit d'indiquer l'extension des fichiers devant etre traités comme des binaires dans un fichier de conf).
Par contre, ce que CVS ne permet pas de faire de facon aisée, ce sont les "reserved checkout", et ça, c'est qd meme dommage, surtout dés lors qu'on se retrouve a bosser a plusieurs sur un meme fichier ...
Bref, pour avoir fait du CVS et du clear-case (l'outil de conf des entreprise qui coute super cher), le seul truc qui manque a CVS, c'est de pouvoir faire du "reserved checkout" plus facilement et plus efficace ...
[^] # Re: Subversion RC-1
Posté par mat1 . Évalué à 7.
CVS le fait mais de façon pas très classe il me semble et de façon non atomique (Le renommage c'est une suppression puis une création et donc perte de l'historique).
Prend le temps de lire la doc de subversion et tu verras que subversion est clairement "potentiellement" meilleur.
[^] # Re: Subversion RC-1
Posté par patatorz . Évalué à 2.
Ca aurait été interessant d'apporter qqes "vraies" nouveautés non ?
Alors lesquelles, hormis le "reserved checkout", je ne sais pas puisque c'est des nouveautés :-)
Pour info, le "reserved checkout" permet de travailler sur un fichier sans que qq'un d'autre puisse le commiter pdt que vous travaillez dessus (on ne peut que le consulter), jusqu'a ce que vous l'ayez commité. Avec CVS, c'est "le 1er qui commit qui gagne", ca peut être génant ...
[^] # Re: Subversion RC-1
Posté par mat1 . Évalué à 1.
On peut tout faire avec CVS en se débrouillant bien.
Comme on peut faire de la programmation objet avec le C ... mais c'est mieux supporté avec le C++.
[^] # Re: Subversion RC-1
Posté par Philip Marlowe . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Subversion RC-1
Posté par Alan_T . Évalué à -2.
[^] # Re: Subversion RC-1, Eiffel
Posté par free2.org . Évalué à 3.
[^] # Re: Subversion RC-1, Eiffel
Posté par bmc . Évalué à 3.
[^] # Re: Subversion RC-1
Posté par Olivier Serve (site web personnel) . Évalué à -2.
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 2.
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Subversion RC-1
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
Bien sur, ce n'est pas du "reserved checkout" à la WebDav, mais de là à dire que c'est "le 1er qui commit qui gagne" il y a un pas tout de même...
[^] # Re: Subversion RC-1 arch ?
Posté par free2.org . Évalué à 3.
http://wiki.gnuarch.org/moin.cgi/FrontPage(...)
[^] # Re: Subversion RC-1
Posté par Nap . Évalué à 2.
lors d'un commit, le fichier du serveur est-il écrasé ou fusionné ?
Si il est fusionné, en quoi ça pose problème que "le 1er qui commit qui gagne" ? Le premier utilisateur archive sa modification, le suivant la sienne, et le résultat possède bien les 2 modifs, non ?
le seul problème arrive si les 2 personnes modifient la même portion de code. Dans ce cas le verrou est nécessaire effectivement
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 2.
Ca ne nécessite pas de verrous (mais il y a quand même possibilité d'en mettre).
[^] # Re: Subversion RC-1
Posté par Nap . Évalué à 1.
Ce que j'appelle fusionné c'est ça :
il y a un fichier sur le serveur, tu le récupère, tu fais des modifications. quand tu effectue le commit, le serveur repère les modifications et les effectue (et garde bien sûr le diff avec l'ancien état, ça va de soit). Comme ça, si quelqu'un a lui-même fait des modifications entre temps, elles ne sont pas perdues, et les tiennes sont cumulées.
Comme tu décris la chose, je considère ça comme un écrasement, car personne ne peut faire une modification en même temps que toi.
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 2.
Dans le cas simple où il n'y a pas de conflits (modifs dans des fichiers différents ou des endroits bien séparés), tout le monde peut travailler en même temps et à partir de la même version, puis chacun fait un update+commit qui se passera bien. Quel que soit l'ordre des commits, toutes les modifs seront cumulées dans la version "actuelle" du serveur.
[^] # Re: Subversion RC-1
Posté par Nap . Évalué à 1.
ça va alors, ça me paraissait le b a ba d'un truc de gestion de sources
je me mettrais bien à ce genre de trucs, je vais peut etre essayer arch pour mes projets perso.
[^] # Re: Subversion RC-1
Posté par allcolor (site web personnel) . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 2.
Si le fichier que tu as modifié n'a pas été modifié par quelqu'un d'autre, il doit l'accepter (éventuellement en disant bien de ne commiter que celui-là). Mais il me semble préférable de faire un update, vérifier que tout marche toujours, puis commiter, je pense qu'avec ce que tu proposes on peut se retrouver avec une version "courante" dans le repository qui ne compile plus.
[^] # Re: Subversion RC-1
Posté par Nap . Évalué à 2.
Je pense qu'avec un bon issue tracking histoire de pas faire la même chose que le collègue, ça ne peut pas poser de pb...
[^] # Re: Subversion RC-1
Posté par Philippe F (site web personnel) . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 3.
Gestion des répertoires et commit atomiques, ça ne me paraît pas de "petites" nouveautés...
[^] # Re: Subversion RC-1
Posté par Antoine J. . Évalué à 8.
-1 et -->[]
[^] # Re: Subversion RC-1
Posté par kesako . Évalué à 4.
-> -> []
[^] # Re: Subversion RC-1
Posté par bmc . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par flyer . Évalué à 1.
Mais la grande nouveauté par rapport à CVS est bien le commit atomique.
Ce commit atomique permet, entre autre, de répliquer rapidement des correction de bugs d'une branche à l'autre.
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par grafit . Évalué à 3.
ah ?
et que font les commandes "watch" et "edit" ?
http://www.cvshome.org/docs/manual/cvs-1.12.5/cvs_10.html#SEC92(...)
[^] # Re: Subversion RC-1
Posté par tripa . Évalué à 1.
Elles ne font que de l'incitation. Quand on est nombreux sur une même base CVS, l'incitation ne suffit pas toujours...
[^] # CVS et les Reserved checkout
Posté par gael s. . Évalué à 1.
puis cette fonction est passée en status "deprecated".
parce que cette fonctionalité n'est pas pratique du tout.
Le grand principe de CVS, c'est le MERGE.
alors Subversion, je veux bien... faut voir.
[^] # Re: Subversion RC-1
Posté par chaostech . Évalué à 1.
Sinon le fait que cvs ne gere pas le reserved checkout et un choix phylosophique de l'equipe de developpement de CVS. Si plusieurs personnes travaillent sur un meme fichier ils sont sensés se prevenir a coup de cvs edit ... mais edit n'interdit pas de remonter un fichier edité par qq1 d'autre. Je pense que le mode edit+merge est tres bien pour les projet developé sur le net , ca t'evite d'envoyer des mails a plein de gens pour qu'il deloquent leurs fichiers et te laisse travailler...mais si tu travail sur un projet où les gens ne sont pas trop conserné par ce qu'ils font tu t'appercois que le merge a des defaut aussi ... J'ai deja vu des fichiers remontés dans la repository avec des conflit dedans ...
[^] # Re: Subversion RC-1
Posté par Philippe F (site web personnel) . Évalué à 1.
A mon avis, dans ce genre de situation, tu peux t'attendre a des milliers de problemes, et pas seulement cote gestion de source.
Cela dit, je pense que CVS reste un outil tres adapte meme pour ce genre de situation. En gros, les gens font n'importe quoi donc il te faut plus de controle: tu envoies tous les diff par mail, et comme ca tu controle.
Tu peux aussi aller vers des mesures de controles en faisant touner des scripts qui autorisent ou pas un commit. Tu peux meme ouvrir une branche reservee au neuneu et n'integrer leurs modifs que lorsque tu as valide qu'ils avaient fait leur boulot correctement.
Sinon, tu peux passer a une solution plus musclee, genre bitkeeper, qui permet de valider chaque commit manuellement, ou qui permet de developper dans un sous-deposoir qui n'est remonte sur le deposoir principal que lorsque tu le choisis.
Je connais des boites qui gerent des projets de plusieurs millions de lignes sous CVS sans aucun probleme.
> J'ai deja vu des fichiers remontés dans la repository avec des conflit dedans ...
Je qualifierai ca d'incompetence. C'est des developpeurs tes neuneus ?
[^] # Re: Subversion RC-1
Posté par chaostech . Évalué à 1.
bugger serait plus addapté, comme l'inverse de debugger ... et regardes sur un dico anglais ce que ca veut exactement dire et tu sauras ce que je pense de mes neuneu ...
Sinon, on filtre les commit et c'est vraie que ca limite bien les problèmes, mais personne n'est designé pour vérifier que les modifications faites par les autres sont valides...
[^] # Re: Subversion RC-1
Posté par Olivier ROSET (site web personnel) . Évalué à 1.
Ca peut manquer. par exemple, dans la boite ou je bosse actuellement, cvs a été rejeté parce qu'il ne gère pas les fiches de suivi. C'est bien dommage, car en entreprise, quand il y a 200 développeurs, ca peut être utile.
[^] # Re: Subversion RC-1
Posté par Quetzalcoatl . Évalué à 4.
ok, mais ça n'est quand même pas du tout pratique. Subversion va peut-être améliorer ces processus
il gère bien les répertoires
s/bien//
Il n'intègre pas de processus identique aux fichiers pour les répertoires. Je ne vois pas trop ce que ça pourrait donner, mais ça pourrait être quand même sympa d'avoir la même gestion qu'avec les fichiers
les "reserved checkout"
C'est quoi ?
[^] # Re: Subversion RC-1
Posté par clem . Évalué à -1.
[^] # Re: Subversion RC-1
Posté par Gloo . Évalué à 1.
autant utiliser rcs... Je condidère ca comme une regression.
[^] # Re: Subversion RC-1
Posté par daggett . Évalué à 3.
Les seuls trucs (crades) que j'ai vu sont de ce style: http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_14.html(...)
[^] # Re: Subversion RC-1
Posté par patatorz . Évalué à 0.
Aprés, c'est vrai que le renomage de répertoire est discutable et que c'est plus commode de le faire en direct sur le serveur ... mais je trouve que ca reste "maigre" comme amélioration (en lisant l'article sur dlfp, on dirait que CVS ne sait pas le faire alors que c'est faux).
Mais ca n'est qu'un point de vue ... si dans tes projets tu as souvent besoin de renomer des répertoires, c'est sur que c'est génant.
[^] # Re: Subversion RC-1
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
> "magouille" sur le serveur
Wahoo, trop fort !
Moi, je le fait avec "mv" et "cp", et sans CVS :
cp toto.c toto.c.bak
mv toto.c titi.c
Et hop, ça roule !!!
Ta solution, c'est vraiment une bidouille :
* Pas de gestion efficace de l'historique. Normalement, on ne conserve que les diffs, là, il faut tout dupliquer
* Pas de gestion correcte des logs. un "cvs log" sur le nouveau fichier ne donne pas l'historique avant le renomage
* Pour naviguer dans l'historique, bonjour ! Exit le cvs annotate, cvs diff, ...
[^] # Re: Subversion RC-1
Posté par patatorz . Évalué à 0.
Ensuite, pour ma part, qd je vire/deplace un fichier, je mets dans le commentaire du commit le pourquoi du comment et le nouveau nom ...
Bon, je me suis bien amusé avec ce troll, j'arrête là ...
[^] # Re: Subversion RC-1
Posté par mat1 . Évalué à 3.
Tu peux estimer que pour ton usage et ton expérience avec CVS, subversion n'apporte rien et je te crois. Mais si tu considère CVS et Subversion comme des outils avec des caractéristiques, Subversion apporte plein de choses (utile ou non, c'est une autre histoire).
D'ailleurs il y a plein de gens qui bossent sans utiliser de gestionnaire de version et qui se demandent à quoi ça pourrait leur servir...
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 2.
Ils le savent, les défauts de CVS sont connus et reconnus, mais tout résoudre revient à reprendre tout à zéro. C'est ce que fait l'équipe de Subversion. Quant à CVS il reste très utile, très stable, il est juste important d'en connaître les limitations et de ne pas s'imaginer qu'on peut tout faire avec en bidouillant le repository.
[^] # Re: Subversion RC-1
Posté par ldng . Évalué à 3.
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 5.
Ben non. « Sans magouilles » ça veut dire avec des commandes CVS, et sans toucher au repository à la main.
De plus même avec cette magouille ça marche mal puisque l'historique est cassé là où tu fais cette opération : elle n'est pas mémorisée dans l'historique du projet global.
[^] # Re: Subversion RC-1
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 5.
CVS sait gérer les ajouts, la suppression et la modification de fichiers.
Pour tout ce qui concerne :
- les répertoires
- les déplacements
- les "renommages" de fichiers ou de répertoires
CVS ne gère pas d'historique, c'est un problème connu de CVS et qui limite énormément les modifications de structuration du code source. Il faut donc quelque chose d'un minimum abouti pour pouvoir commencer à gérer efficacement les versions.
Il sait aussi gérer les fichiers binaires
On peut intégrer des fichiers binaires dans un dépôt CVS, il gèrera l'historique, mais pas les différences. Enfin là, c'est assez logique parce que gérer les différences sur une image ou sur un échantillon de son, ça n'a rien à voir (et c'est assez difficile à définir).
CVS ne permet pas de faire de facon aisée, ce sont les "reserved checkout"
Je ne connais pas ce terme, mais il existe avec CVS les possibilités suivantes :
- notifications d'une modification (via un watch, avec les commandes edit, release et commit)
- verrouillage d'un fichier (pas terrible à mon sens)
L'autre problème, c'est que CVS gère l'historique de fichiers de façon indépendante les uns des autres. Impossible d'exprimer qu'une même modification implique plusieurs fichiers.
Bon, cela dit il me reste à évaluer Subversion et Arch (dont quelqu'un va à coup sûr parler dans les commentaires à suivre).
[^] # Re: Subversion RC-1
Posté par Frederick Ros . Évalué à 10.
J'ai commence a regarder arch y'a qq temps, et ce qui m'a frappe en premier lieu .. c'est la qualite du tutorial/doc ....
Ca a l'air simple, c'est oriente changeset, tu peux facilement partager tes archives (http,ftp,sftp) ...
Y'a l'ajout des signatures/integrite dans les dernieres versions.
Chaque element du repository a 2 noms: un nom correspondant au path, et un nom interne .. Lors de l'application de modifications, celles-ci sont faites en utilisant le nom "interne" pour designer le fichier .. Du coup si le fichier a ete renomme dans l'archive courante (i.e: son path a change), et bien les modifs seront bien faite sur le fihcier portant le nouveau nom ..
Les branches ont l'air d'etre simple a faire et a utiliser ...
Ca me botte assez ....
[^] # Re: Subversion RC-1
Posté par Yves Martin . Évalué à 1.
Si le commit de tous les fichiers est fait en une fois, on peut considérer que si mais ce n'est pas parfait. A supposer qu'on ne fasse l'update que sur le fichier en conflit (par exemple), on obtient qq chose d'incohérent (qui ne compile pas en général), donc la parade: faire des update intégrals régulièrement avant de compiler/tester/commiter.
Des outils permettent aussi de retrouver les commit qui ont le même log et des dates proches pour constituer un patch...
[^] # Re: Subversion RC-1
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
> les sources possédant une arborescence).
Oui, mais comment !
mkdir toto
cvs add toto
Ah, tiens, pas besoin de faire de commit ? Ben non, le cvs add fait un mkdir sur le repository, et c'est tout. Bon, déjà, c'est contraire au principe "Une modification locale n'est vue des autres utilisateurs qu'à partir du moment ou elle est commitée".
Bon, maintenant, on veut supprimer un répertoire. Ben la différence entre un répertoire vide et pas de répertoire du tout en CVS, c'est maigre.
Maintenant, je veux naviguer dans l'historique de ce répertoire. Tiens, il a été créé quand ? Par qui ?
[^] # Re: Subversion RC-1
Posté par PachaFonk . Évalué à 3.
- Chaque developpeur est censé bosser dans sa branche (avec CVS, ta branche, c'est les fichiers en local sur ton disque).
- Quand les developpeurs ont terminé leur travail sur leur branche, ils sont cencé merger leur modifications... c'est à ce moment là que les conflits sont gérés...
Le "reserved checkout" n'est utilisable que sur les petits projets, car il empêche tous les autres develloppeurs de travailler sur le fichier que tu as réservé.
[^] # Re: Subversion RC-1
Posté par Romain Vinot . Évalué à 1.
Si tu y tiens vraiment, tu peux prendre RCS...
[^] # Re: Subversion RC-1
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 0.
"Reserved chckout : pour ou contre" c'est une histoire de gouts/besoins. Inutile de développer plus.
Pour ma part, je dirais que cela dépends essentiellement de la capacité à faire de 'merge'. Quand on travaille avec des gars qui font de la programmation 'alimentaire' c'est assez rassurant de ne pas avoir à leur confier la responsabilité d'un merge.
Mais bon, j'avais dit que je dirais rien, alors j'en dis pas plus.
[^] # Re: Subversion RC-1
Posté par PachaFonk . Évalué à 2.
J'essaye juste d'expliquer pourquoi le "Reserved checkout" n'est pas utile.
une explication plus complète : http://svnbook.red-bean.com/html-chunk/ch02s02.html(...)
[^] # Re: Subversion RC-1
Posté par flyer . Évalué à 2.
Dans ce cas la seul solution c'est le dialogue. Les personnes succeptibles de travailler sur ces fichiers doivent communiquer pour indiquer lorsqu'elles travaillent dessus.
[^] # Re: Subversion RC-1
Posté par matli . Évalué à 3.
Au final, c'est assez contre-productif à mon gout, d'autant plus que les conflits dans les merge viennent du fait que 2 personnes ont au même moment travaillé sur une même portion de fichier et là, il y a peut être un problème d'organisation.
[^] # Re: Subversion RC-1
Posté par bmc . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par Nap . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par Gloo . Évalué à 1.
Et la durée est en fonction de quoi ?
Le reserved check-out est une regression. J'ai été "obligé" de travailler avec PVCS (qui est une sombre merde au passage). Je n'ai malheureusement pas compté le temps perdu dans les couloirs et au téléphone pour rappeler aux gens de retirer leurs locks , ni le temps perdu à cause du soft: plantage, lenteur etc...)
Quand le travail est à peine organisé, la probablité de commiter le même fichier au même instant est faible, la probabilité de commiter une difference sur la même ligne, est extremement faible, et, le cas écheant, les conflits se règlent très facilement dans la très large majorité des cas.
Pour les fichiers binaires, je ne crois pas qu'ils ont leur place dans un CVS parce que le "C" de cvs c'est justement pour "Concurrent" et que cvs n'a pas pour vocation de gerer des binaires dont il ne sait rien... pas plus que les humains. Enfin bon, y a toujours moyen de versionner des binaires avec cvs.
Bref (ca n'engage que moi):
- Gestion des répertoires.
cool, ca fait d'avantage produit fini que cvs (mais on peut s'en passer ou contourner)
- Possibilité de renommer et déplacer des fichiers.
idem.
- Ajout de méta-données sur les fichiers
Elles s'integrent avec quoi les méta-données ? Sinon l'historique cvs et les commentaires dans les fichiers ou générés me suffisent largement.
- Possibilité d'utilisation d'Apache comme serveur et de WebDAV /DeltaV comme protocole.
Au secours !
- Optimisation de l'utilisation de la bande passante
Quoi de plus par rapport à CVS ? (compression/patch)
- Gestion simplifiée des fichiers binaires
Bein je trouve pas ca trop compliqué avec cvs:
http://www.cvshome.org/docs/manual/cvs-1.12.5/cvs_9.html#SEC80(...)
J'ajoute:
- les commits atomiques
C'est un truc marketing ? Tout est commité ou rien n'est commité ? si quelqu'un fait un update/commit pendant un autre commit (atomique) il attend que le commit/rollback soit fini ? Bref l'utilité doit se reveler au moment où 1000 devs travaillent sur le même projet en faisant tous des commits/update "critiques" de façon continu. Je n'ai jamais eu la "chance" de travailler sur ce type de projet :o)
Bein voilà, s'il y a de vrais avantages à utiliser subversion, je ne crois pas qu'ils soient dans la liste de la news. On va dire que c'est l'ensemble qui fait que subversion est peut être plus interessant que cvs. Bein oui, changer, ca a un coût, c'est un soft recent qui ne s'integre pas à grand chose, et que quasi personne ne connait.
[^] # Re: Subversion RC-1
Posté par Philippe F (site web personnel) . Évalué à 1.
9h du matin: ok, 10s pour se connecter a la base
10h du matin: ok, 30s pour se connecter a la base
11h du matin: pas ok, 3 minutes pour se connecter a la base
3h de l'aprem: pas ok, plantage de la base parce que trop d'utilisateurs connectes en meme temps.
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 2.
Qu'apporte subversion de plus par rapport à CVS ?
- Gestion de l'historique des modification apportés aux répertoire
- Possibilité de renommer/déplacer des fichiers en conservant l'historique
- Copie de fichier avec gestion de l'historique
- Gestion simplifiée des fichiers binaires (simplifié voulant dire sans config spéciale)
...
Bon c'est vrai que ça a pas l'air immense par rapport à CVS, mais c'est quand même bien pratique...
Personellement, j'ai utilisé CVS et subversion pour des petits projets plutôt personnels.
Il faut avoir utilisé subversion pour bien se rendre compte de ce qu'il apporte par rapport à CVS...
En gros, CVS gère l'historique de fichiers et de leur contenu, Subversion gère l'historique de répertoires et de leur contenu(fichier et contenu des fichiers)... C'est un peu raccourci comme vue, mais à l'utilisation c'est ce qui ressort...
Bon évidemment, il y en aura toujours pour critiquer dénigrer, ...
Je n'ai qu'une seule réponse à ceux là: testez et si ça ne vous plait pas, continuez d'utiliser vos outils actuels, ou créez votre propre projet....
[^] # Re: Subversion RC-1
Posté par Jean-Marc Spaggiari . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 2.
Et puis il y a aussi des optimisations pour les transfers de fichiers (passage des diff plutot que des fichiers complets) qui nécessitent une réécriture du protocole de communication entre client et serveur...
Donc quitte à rendre les clients et serveurs actuels incompatibles, autant tout modifier non ?
[^] # Re: Subversion RC-1
Posté par #3588 . Évalué à 2.
Parce que ce ne sont pas juste des optimisations ! Si ça avait été possible avec CVS, je crois que l'équipe de CVS l'aurait fait depuis longtemps. On est vraiment dans un de ces cas où les fonctionnalités voulues nécessitaient une réécriture complète.
[^] # Re: Subversion RC-1
Posté par flyer . Évalué à 2.
- commit atomique (LA fonctionnalité qui manque dans CVS)
- gestion des branches et des tags extrêmement simple
- réplication des corrections de bugs entre les branches extrêment simple.
- renommage/déplacement des fichiers et répertoires avec conservation de l'historique
[^] # Re: Subversion RC-1
Posté par Gloo . Évalué à 2.
- gestion des branches et des tags extrêmement simple
- réplication des corrections de bugs entre les branches extrêment simple.
"
A mes yeux, cela devrait être dans la liste des avantages de subversion de la news.
Tu as un lien qui explique comment, par exemple, commiter un bugfix sur plusieurs branches au choix en une seule commande ?
[^] # Re: Subversion RC-1
Posté par flyer . Évalué à 2.
http://svnbook.red-bean.com/html-chunk/ch04s03.html(...)
en résumé:
- je corrige un bug dans la branche nommée "superdev". Je commit la branche et le repository incrémente le numéro de révision. Disons que le nouveau numéro de révision est 123.
- maintenant je veux appliquer cette correction de bug dans la branche principale (nommée trunk) je n'ai qu'à faire :
svn mergre -r 122:123 http://svn.example.com/repos/branches/superdev(...)
Même si la correction de bug intervient sur plusieurs fichiers, toutes les modifications seront appliquées à la branche principale.
Plus dans le détail:
positionnement sur la branche superdev:
# svn switch http://svn.example.com/repos/branches/superdev(...)
modifications des fichiers de la branche, commit:
# svn commit
(nouveau numéro de révision 123)
repositionnement sur la branche trunk:
# svn switch http://svn.example.com/repos/trunk(...)
application de ces modifications sur cette branche:
# svn mergre -r 122:123 http://svn.example.com/repos/branches/superdev(...)
commit:
#svn commit
On peut aussi répliquer plusieurs ensembles de modifications (c'est à dire plusieurs commits ou plusieurs corrections de bug) d'un seul coup, d'une branche à l'autre de la même manière. Il suffit pour ça de jouer avec les -r 999:999. Je crois que tant que l'on a pas lu le SVN Book on ne sait pas vraiment ce qu'est subversion:
http://svnbook.red-bean.com/html-chunk/index.html(...)
# Hors sujet (quoi que)
Posté par Nicolas Regnault . Évalué à 2.
Cette possibilite existe-t-elle avec cvs? Et avec subversion, cela est-il faisable/plus facile?
[^] # Re: Hors sujet (quoi que)
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
Si ce que tu cherches est une gestion de droits d'écriture en fonction de l'utilisateur, je n'ai jamais cherché dans ce sens mais je ne pense pas que ce soit possible avec CVS. Pour Subversion, je laisse les connaisseurs répondre, je serai curieux de savoir :)
[^] # Re: Hors sujet (quoi que)
Posté par franck villaume (site web personnel) . Évalué à 5.
Cf page 90 de la documentation subversion revision 8263
--------
C01N C01N
[^] # Re: Hors sujet (quoi que)
Posté par Yves Martin . Évalué à 1.
[^] # Re: Hors sujet (quoi que)
Posté par tripa . Évalué à 1.
Peut-être avec un export? (mais j'ose pas imaginer la situation si tu as besoin de modifier certains répertoires et pas d'autres)
[^] # Re: Hors sujet (quoi que)
Posté par Olivier Jeannet . Évalué à 3.
Tu peux aussi faire ça avec le fichier "commitinfo" qui est dans le sous-répertoire administratif "CVSROOT" (c'est donc $CVSROOT/CVSROOT/commitinfo). Voici le début du fichier :
# The "commitinfo" file is used to control pre-commit checks.
# The filter on the right is invoked with the repository and a list of files to check. A non-zero exit of the filter program will cause the commit to be aborted.
#
# The first entry on a line is a regular expression which is tested against the directory that the change is being committed to, relative to the $CVSROOT. For the first match that is found, then the remainder of the line is the name of the filter to run.
# [...]
[^] # Re: Hors sujet (quoi que)
Posté par Nicolas Regnault . Évalué à 1.
[^] # Re: Hors sujet (quoi que)
Posté par Éric (site web personnel) . Évalué à 1.
En gros pour chaque adresse tu peux définir quels utilisateurs et groupes ont les droits d'écritures et quels utilisateurs et groupes ont des droits de lecture.
Pour restreindre le sous rep /admin à un groupe ou un utilisateur ?
[/admin]
@groupelecture = r
userecriture = rw
On fait difficilement plus simple
[^] # Re: Hors sujet (quoi que)
Posté par Philippe F (site web personnel) . Évalué à 1.
# Re: Subversion RC-1
Posté par franck villaume (site web personnel) . Évalué à 3.
- facilité de prise en main par l'utilisateur lambda. (La commande line est proche de celle d'unix)
- le tout réseau intégré par défaut
- le scripting facile de subversion
- api python, perl, et C
Et les outils connexes que j'utilise :
- cvsweb comme interface web détaillée
- SVN::Web pour la gestion de l'historique
Voilà quoi.
---------
C01N C01N
[^] # Re: Subversion RC-1
Posté par franck villaume (site web personnel) . Évalué à 1.
J'aurais dû prendre mon café....
----------
C01N C01N
[^] # Re: Subversion RC-1
Posté par Yves Martin . Évalué à 1.
http://www.onlamp.com/pub/a/onlamp/2004/01/29/scm_overview.html(...)
Finallement Subversion n'est pas conçu pour être distribué - CVS non plus mais cette fonctionnalité me semble importante pour des projets OpenSource world-wide... Arch est distribué d'après ce que j'ai lu.
Bref, le choix est dur. Et finallement en connaissant les défauts de CVS, on s'en accomode très bien.
[^] # Re: Subversion RC-1
Posté par mat1 . Évalué à 5.
et
> Et finallement en connaissant les défauts de CVS, on s'en accomode très bien.
Pour Subversion un défaut est "très limitant" ; pour CVS, "on s'en accomode très bien"...
[^] # Re: Subversion RC-1
Posté par grafit . Évalué à 3.
C'est sur que sur le plan purement technique, ca sent le parti pris ;)
# Re: Subversion RC-1
Posté par Romain Vinot . Évalué à 1.
Il en existe des dizaines pour CVS, mais je n'ai pas trouvé pour Subversion...
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 1.
Je ne l'ai pas essayé moi même, mais je sais que eclipse permet de faire ce genre de chose entre un fichier local et un fichier distant (par ex en sftp)...
Je suppose donc que le plugin subversion intègre ce genre de choses...
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 1.
http://subclipse.tigris.org/(...)
[^] # Re: Subversion RC-1
Posté par grafit . Évalué à 1.
[1] http://meld.sourceforge.net/(...)
[^] # Re: Subversion RC-1
Posté par flyer . Évalué à 2.
# Re: Subversion RC-1
Posté par Alan_T . Évalué à 1.
Et il se trouve qu'avec CVS, je me fait souvent (très souvent, même) ce genre de réflexion. Je suis donc heureux que d'autres logiciels arrivent enfin sur le marché.
Les gros désavantages de CVS sont (à mon humble avis):
- Une mauvaise gestion du renommage des fichiers
(perte de l'historique à chaque renommage)
- Peu ou pas du tout de gestion des répertoires
- Une execrable gestion des droits sur les fichiers
(pour ceux qui ont déjà essayé de donner les droits en lecture seule à un groupe d'utilisateurs et en lecture/écriture pour un autre et cela en essayant de ne pas créer de nouveau groupe puisque pas root sur le système...)
- Une administration qui tourne rapidement au cauchemard
- Une utilisation compliquée (surtout lorsqu'on doit passer par toute sorte de passwords)
- .... j'en oublie sûrement...
Les alternatives qui existent semblent être:
o CVS (http://www.cvshome.org/(...))
o Subversion (http://subversion.tigris.org/(...))
o arch (http://www.gnu.org/software/gnu-arch/(...))
o Bitkeeper (http://www.bitkeeper.com/(...))
o autres.... ?
Quelqu'un a-t-il déjà évalué les différents avantages/inconvénients de chacun de ces systèmes ?
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 1.
Pour la gestion renommage des fichiers, répertoires, ... subversion le fait sans problème.
Pour la gestion des droits d'accès, si tu utilise subversion en réseau avec apache, tu configure les accès via apache => tu peux donc contrôler les droits d'accès aux répertoires pour chaque utilisateur (lecture et ou écriture).
Pour le reste, c'est plutôt subjectif... à essayer... :)
[^] # Re: Subversion RC-1
Posté par Frederick Ros . Évalué à 5.
http://better-scm.berlios.de/comparison/(...)
[^] # Re: Subversion RC-1
Posté par Alan_T . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par Alan_T . Évalué à 2.
Pour des projets importants --> subversion
Pour de petits projets ou pour ses archives personnelles --> Arch
En effet, subversion semble être long à installer, vu sa liste de pré-requis (module Apache, Berkeley DB, etc...).
Ai-je tort ?
[^] # Re: Subversion RC-1
Posté par Alan_T . Évalué à 2.
http://better-scm.berlios.de/subversion/compelling_alternative.html(...)
[^] # Re: Subversion RC-1
Posté par Alan_T . Évalué à 1.
Est-il vrai que le changelog peut être généré automatiquement (c'est une fonctionalité bien utile!).
[^] # Re: Subversion RC-1
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Subversion RC-1
Posté par Edouard Gomez (site web personnel) . Évalué à 3.
http://ed.gomez.free.fr/projects/xvid-devapi4/ChangeLog-devapi4.txt(...)
Bon il faut savoir que je maintiens cette branche dans une archive Arch tout seul, donc je suis obligé de dire "From truc" pour tracer un peu a qui on doit tel ou tel patch. Mais si les autres dev utilisaient arch , le "qui a fait quoi" serait géré automatiquement, et ferait parti de l'historique. Voir un mail assez recent sur xvid-devel:
http://article.gmane.org/gmane.comp.video.xvid.devel/3757(...)
Trois branches, la mienne ne servant qu'a l'integration du travail des 2 dev PPC.
NB: les logs automatiques sont generes par "branche".
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 1.
Bon c'est pas nécessairemet le format de changelog qui est utilisé un peu partout, mais c'est juste cosmétique... :)
Un petit exemple ci-dessous:
------------------------------------------------------------------------
rev 137: olivier | 2003-02-05 00:58:35 +0100 (mer, 05 fév 2003) | 3 lines
Changed paths:
M /yafi/NEWS
M /yafi/TODO
M /yafi/configure.ac
M /yafi/python/analyser.c
M /yafi/scripts/sources/yafi-latex
Removed a compilation bug.
Changed release version to 0.3.1
------------------------------------------------------------------------
rev 136: olivier | 2003-02-03 02:28:28 +0100 (lun, 03 fév 2003) | 1 line
Changed paths:
M /yafi/README
[^] # Re: Subversion RC-1
Posté par flyer . Évalué à 1.
svn log -xml > log.xml
Ensuite il ne reste qu'à écrire un fichier XSL (ou en reprendre un d'internet il en existe déjà) et à le passer dans un processeur XSLT (sablotron par exemple) et voilà un changelog tout beau tout bien présenté.
[^] # Re: Subversion RC-1
Posté par Olivier Samyn (site web personnel) . Évalué à 1.
Le log xml n'existait pas encore (si j'ai bon souvenirs :) )
[^] # Re: Subversion RC-1
Posté par mat1 . Évalué à 2.
Pour la partie client c'est très rapide et on trouve facilement des paquets.
Pour la partie serveur ça rapide maintenant (ça dépend de ta distribution) :
http://subversion.tigris.org/project_packages.html(...)
Ya des dépots apt pour debian, yum pour redhat ...
Pour les prérequit, ça devient petit à petit du standard. Pour fedora, il faut ajouter apr (qui est déjà livré mais la version doit être trop ancienne) et neon.
Donc dans un proche avenir, pour avoir subversion (client et serveur) il faudra ajouter neon par rapport à une distribution standard.
[^] # Arch vs. les autres (etait: Re: Subversion RC-1)
Posté par David Mentré . Évalué à 5.
Pour moi, les gros avantages de Arch (dans le désordre):
- commit atomic avec des changset => si on l'utilise correctement, chaque commit correspond à un changement du système (correction de bug, nouvelle fonctionnalité, ...)
- fonctionnement en mode décentralisé. Pas besoin de serveur. Si on a une page web, on peut mettre un mirroir de son archive disponible en FTP/HTTP/WebDAV que les autres peuvent récupérer. C'est typiquement le fonctionnement des projets libres
- activement développé. Réponses rapides sur la mailing list gnu-arch-users.
- logiciel libre
Cela dit, je n' ai pas testé sur de gros projets ou avec des branches multiples. Donc impression à revoir dans quelques temps.
Pour ceux qui voudraient utiliser Arch, jeter un coup d'oeil sur son Wiki, c'est bourré d'infos utiles.
[^] # Re: Arch vs. les autres (etait: Re: Subversion RC-1)
Posté par Frederick Ros . Évalué à 2.
[^] # Re: Arch vs. les autres (etait: Re: Subversion RC-1)
Posté par Alan_T . Évalué à 3.
Voir: http://wiki.gnuarch.org/moin.cgi/FrontPage(...)
Et particulièrement: http://wiki.gnuarch.org/moin.cgi/Learning_20Arch_20commands_20for_2(...)
# killer feature
Posté par PachaFonk . Évalué à 5.
Il permet de passer les firewalls car il utilise le protocole http (WebDAV) et permet donc d'acceder à une archive de partout !
[^] # Re: killer feature
Posté par Alan_T . Évalué à 2.
[^] # Re: killer feature
Posté par bmc . Évalué à 1.
[^] # Re: killer feature
Posté par gabuzo . Évalué à 2.
[^] # Re: killer feature
Posté par Philippe F (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.