Travaillant habituellement avec CVS j'ai toujours été un peu rétiscent pour essayer des alternatives du style Arch ou Subversion : des commandes différentes, des moyens de stockage différents, etc. Bref, ça fait peur.
 
Mais bon, aujourd'hui et pour une raison inconnue, je me suis mis à lire la doc de Subversion, à l'émerger, à suivre quelques tutoriaux et à jouer un peu avec.
 
Bein... C'est mortel.
 
Déjà il est totalement utilisable sans Apache 2, Webdav et compagnie. Ce n'était peut-etre pas les cas des premières versions, mais maintenant ça fonctionne très bien sans (sauf si vous avez vraiment besoin de Webdav, sinon le serveur fourni avec Subversion suffira) .
 
Les projets existants en CVS peuvent etre convertis sans problème au format Subversion; un script pour faire ça est fourni et il fonctionne nickel. Tout l'historique est conservé.
 
Au niveau des commandes... bein... en gros c'est exactement les memes que pour CVS : checkout, checkin, rm, add, commit, diff, import, export... tout ça fonctionne de la meme façon en gros il suffit juste de remplacer "cvs" par "svn".
 
Sauf que... tous les trucs vraiment relous avec ces commandes sous CVS ne posent aucun soucis sous Subversion. Genre pour déplacer/renommer des répertoires, un "svn mv" fonctionne nickel.
 
Les dépots sont spécifiés sous forme d'URL. Et en fait pour chaque commande, vous pouvez travailler sur des dépots spécifiés comme des répertoires locaux ou des URLs de dépots distants. Pour importer des patches entre deux répértoires locaux et recopier le résultat dans un dépot distant, c'est d'une incroyable simplicité comparé à CVS.
 
Dans un répertoire de travail, tout le bordel de Subversion est stocké dans des dossiers ".svn". Ca fait plus propre que les dossiers "cvs" et surtout ils contiennent l'URL du dépot. Dès l'instant où l'on se trouve dans un répertoire versionné, toutes les commandes de Subversion fonctionnent aussitôt et vont consulter le bon dépot. C'est _très_ pratique.
 
Mais le mieux reste la gestion des branches (ou des tags, c'est la meme chose sous Subversion) . Sous Subversion, vous avez juste à "recopier" un répertoire sous un autre nom pour en créer une branche : svn copy <source> <destination> et c'est torché. Au niveau du dépot les mises à jour se font automatiquement dans la bonne branche en fonction du répertoire dans lequel vous vous situez et les numéros de versions restent globaux.
 
Pour fusionner deux branches, un "svn merge" suivi des versions et des répertoires (ou URLs) et hop, c'est réglé.
 
Que dire d'autre... Le logiciel ViewCVS est parfaitement compatible avec Subversion et permet de consulter aisément un dépot via une interface web... il y a aussi pas mal d'interfaces graphiques en Java ou WxWindows pas forcément très utiles à mon avis, mais bon, elles ont le mérite d'exister.
 
Et si vous pensez "pfou c'est cool mais c'est pas le genre de truc que je peux installer au boulot, les mecs qui bossent sous Windows et qui n'ont jamais entendu parler de CVS et compagnie vont etre paumés", rassurez-vous. A partir du site de Subversion vous pouvez télécharger une extension pour l'explorateur de Windows.
 
Une fois cette extension installée, utiliser Subversion devient un jeu d'enfant, tout est intégré dans un menu contextuel lorsque vous naviguez dans un dossier à partir de l'explorateur.
 
La doc de Subversion est un peu fouilli (je vous recommande de rechercher "Subversion tutorial" sur Google en parallèle) mais le soft est vraiment très bien fait et simple d'utilisation une fois que l'on a mémorisé les quelques commandes qu'il comporte.
 
http://subversion.tigris.org/
 

Alors ca marche sous Windows maintenant ? Va vraiment falloir que je suggère ça au boulot car on a des problèmes avec CVS. Notre système est devenu trop gros pour lui.

Oui ça marche sous Windows aussi.

bonsoir.
je viens d'installer svn sur mon serveur(avec apache2), j'ai initialisé un repo, mais dès que j'essaye de le checkouter (sic), je me mange un 403 forbidden:

j'ai d'abord cru que c'était lié à mon virtualhost, mais là j'ai mis le <Location> en dehors du virtual host et ça marche pas mieux.
Mon apache tourne en tant que www:www
 
un extrait du httpd.conf:

/usr/local/svn est un symlink vers /home/svn/repos

 
une idée?

ça gère les fichiers binaires ?

svn?
gérer dans quel mesure?
(sinon euh bah oui, au moins autant que cvs)

au fait j'ai trouvé mon problème. j'oubliais de mettre /monproject dans mes urls

Pour les GUI sous windows j' ai pas mal utilisé TortoiseSVN que je conseille d' ailleurs il y' a cependant d'autres logiciels/plugins pour des applications specifiques. Comme disait axey ca s' integre directement à l' interface d' explorer.
 
http://tortoisesvn.tigris.org/
 
Pour linux si vous aimez pas la ligne de commande j' ai vu une gui aussi au nom de rapidsvn mais pas testé personnelement.
 
http://rapidsvn.tigris.org/

ben gérer mieux que cvs, c'est à dire avec un diff pour un stockage efficace

ha oui. ben je sais pas...  

parce que ça c'est un problème.

euh ça t'arrive souvent de mettre de gros binaires dans ton vcs toi?

oui. genre quand je bosses pendant 1 ans sur une knoppix, j'ai un peu les boules quand je cherches les différences entre 2 versions pour comprendre ce qui a changé/pété

je vois pas le rapport avec les binaires ?

ben tu vois, ça m'aurait bien aidé pour tout gérer au même endroit. et fichiers de conf /etc en grande partie, plus tous le reste du bordel répartis de partout. j'aurais foutu toutes la distribution dans truc de controle de versions

et comparé à arch ?

attend mais tu fous les *sources* tu fous pas un tgz des sources hein

dis, tu vois la tronche d'une distribution ? les milliers de fichiers que y a dedans ? les centaines de fois ou installes vires des logiciels, modifies un fichier de configuration, ajoute un script, renommes des choses, etc ? ben voilà.
 
2 fois on a du faire un gros retour en arrière et repartir d'une version bien antérieure par ce qu'on était incapable de tracer précisément les différences entre la dernière version cassée et une version qui marche. incapable de dire précisément à quel endroit ça a cassé. alors on reprend une version dont on a conservé une iso, et cai repartit

ben les gens qui *font* ces distribs, j'ose esperer qu'ils utilisent un vcs.
si toi tu es utilisateur de cette distrib, tu peux te contenter de versionner les fichiers que tu y modifies, non?

pis si c pour stocker des iso, ben je vois pas l'interet d'un vcs en fait..

allo ! je te dis que je bosses sur un dérivée de KNOPPIX ! y a presque un an, avec cyplp, on a pris une knoppix et depuis on l'a mise à jour, intégré des kilomètres de soft, reconfigurer des tonnes de bordels avec X, tout virer pour mettre XFCE4 alors qu'il était pas dans debian, etc . mais bon t'as pas l'air de comprendre

ben non en effet, j'avais pas *deviné*
 
la seule façon valable de faire soit de tout foutre sur cvs, soit de tenir des patches à jour que tu appliques a la knoppix originale (ce qui apparement risque de pas etre possible pour vous si vous avez "reconfiguré des tonnes de bordels" )

oui mais le problème, c'est que le va et viens incessent de paquets et de binaires, c'est 1.5Go, alors que le /etc, c'est peut être 10Mo. donc si t'as pas un vcs qui gère le binaire correctement, genre cvs, tu exploses tout. et déjà rien, que se débrouiller avec cvs pour lui faire bouffer du binaire, c'est déjà toute une histoire.
 
comme on a bossé et sur la configuration et sur le contenu, on aurait eu besoin d'un outils mixte

vous avez bien un script quelconque qui builde la distrib complete? pourquoi ne pas faire en sorte que ce script aille chercher les binaires dont vous avez besoin, là ou il faut? (à la façon de maven, en qque sorte, qui va chercher les dependences d'un projet sur un serveur http avant de builder le projet). Il vous suffirait alors de tenir à jour un fichier de config qui reprendrait les differents binaires necessaires.

non spa aussi simple que ça.  
et le truc c'est également que générer l'iso sur notre machine prenait entre 30 et 45minutes, donc on avait pas trop envie de tester 4 fois par jour. résultat, si tu fais une iso par semaine et que tu la testes, c'est impossible de te souvenir de tous les changements que t'as fait depuis 7 jours. un jour on a l'usb qui est parti en couille tout seule, impossible de comprendre, on était en version 0.6rc et boom on est repartit de 0.5c, dernière version connue correcte, genre qui avait 2mois. le mieux aurait était de stocker des iso journalières, mais ça ne te donne pas de différentiels, et ça prends du temps et trop d'espace  disque

http://wiki.gnuarch.org/moin.cgi/S [...] Comparison
 
Distributed and private repositories
 
Repository protected against corruption
 
 
 
ça c'est cool. combien de fois quand on travail sur un patch de son coté sur sa version locale, on est obligé de mailer le patch à tout le monde et de faire tourner le tout. pas de quoi faire une nouvelle branche. juste des modifications conséquentes de plusieurs fichiers (genre réécriture massive ou ajout de fonctionnalité).  
 
je fais le patch, j'envoie à l'autre, il me donne son avis, je modifie 3/4 conneries, renvoie, il est ok, je rajoute des bricoles et hop, on repart pour la même boucle. c'est chiant ça.

Apparemment ça marche bien pour les binaires selon eux
 

 
Je vais m'installer ça moi