Reprise du message précédent :
ça va pas la tête ? je vais pas non plus faire un serveur sous windows aussi !
 
non, j'ai un environnement tout Linux mais faut que les pelés de l'infographie et les commerciales qui sont à Paris puisse cliquer

Si tu leurs fait utiliser CVS, faudra penser à leur apprendre à faire gaffe à la casse des fichiers et surtout à ne jamais renommer/recopier un répertoire

surtout que ce que je cherche ne dois évidemment pas être lié à quoi que ce soit

j'ai essayé svn...ca a pas l'air mal, et l'intégration à eclipse est parfaite...
 
en fait si g bien suivi dès que tu veux modifier qqc tu fais un checkout pour etre sur d'avoir les dernières versions, et tu commit dès que t'a finis pour les autres...
 
-->nraynaud : g vu que t'utilisais un server SVN sur le web...c gratos ? y'a des conditions spéciales à remplir ? (ca m'intéresse pour mes futurs travaux de groupe l'an prochain)
 
 
Mon petit soucis : comment faire un checkin dans un rep donné d'un projet existant ?
 
en fait je voudrais que les sources aillent dans /src et pas à la racine du projet...

up, pour que ce topic deviennet le topic des SCM et qu'on arrete de polluer les autres topics avec ça (en particulier le topic Eclipse)

Voici une petite comparaison entre Subversion et Arch, les deux acteurs majeurs de la gestion de configuration (Software Configuration Management, SCM) dans le domaine du libre, à partir des informations glanées sur le net.
 
Il en existe au moins deux autres intéressants, à savoir Monotone et aussi DARCS, chacun avec leurs avantages et leurs inconvénients. Ces deux programmes ne se composent que d'un simple exécutable, bien qu'ils semblent cacher une grande puissance sous cette apparente simplicité. Mais par manque d'information sur ces deux derniers produits et/ou parce qu'ils ne sont pas encore parvenus à pleine maturité, je me pencherai sur les deux premiers.
 
Arch et Subversion sont aujourd'hui deux produits matures utilisés par de nombreux projets en open source d'envergure et des compagnies privées. Ils sont tous deux technologiquement très supérieurs à CVS, dont l'impossibilité de renommer fichiers et répertoires sans perdre l'historique est une tare extrêmement gênante pour un projet industriel de taille moyenne. (Je signale en passant que l'interface graphique de ClearCase est boguée et pose ce même problème, qui peut faire perdre bcp de temps. Il faut passer par la commande cleartool move pour pouvoir renommer un fichier/répertoire sous ClearCase.)
 
----
 
Subversion est développé sous licence BSD par des mainteneurs de CVS, avec l'ambition d'en être le successeur et remplaçant direct. Il reprend donc la philosophie et le jeu de commandes de CVS, tout en palliant à la plupart de ses défauts.  
 
Avantages   :  
 

• les commit sont atomiques,

• la hiérarchie des fichiers est versionnée (comme dans ClearCase par ex.) --> pas de problème de renommage de répertoires et/ou fichiers. On peut y attacher des méta-informations.

• peut fonctionner comme module Apache à travers le réseau internet ou via un serveur dédié svnserver. Toutes les opérations sont sécurisées.

• plus rapide et moins gourmand que CVS, en particulier pour les binaires.

• un outil permet d'importer un repository CVS directement dans subversion.

• traditionnel. Les habitués de CVS ne seront pas dépaysés.

• multiplateforme

• il existe déjà des interfaces graphiques qui facilitent l'utilisation de svn au quotidien, comme TortoiseSVN sous Windows.

• la documentation est très complète et le support a l'air bon. Une API permet d'interfacer ses propres outils.

Inconvénients   :  
 

• essentiellement, l'absence de fusion (merge) qui tient compte de l'historique. Pour les utilisateurs de CVS, ça ne changera rien, CVS n'ayant pas cette capacité non plus. Pour les utilisateurs de ClearCase, Perforce ou d'autres produits commerciaux qui ravaillent sur plusieurs branches parallèles, par contre, c'est une lacune majeure, tant cette fonctionnalité facilite les opérations de fusion. Nombre de merges continueront donc de se faire manuellement, avec tous les risques d'erreur que cela comporte. Bien que cette fonctionnalité soit prévue sur le long terme, elle est complexe à implémenter et n'est pas encore programmée pour Subversion.

• pas de lock exclusif des fichiers, mais cette fonctionnalité étant prioritaire sur la liste des développements, elle devrait appraître dans une prochaine version (une 1.2 ?).

• pas de fusion possible entre bases (repositories).

• installation du serveur relativement complexe.

• nombreux s'inquiètent du fait que les données sont stockées dans une base BerkeleyDB. En pratique, il ne semble pas que ça pose de réel problème, sachant que je n'ai lu nulle part qu'il n'y ait jamais eu la moindre perte de données, et ce même sur des projets de plus de 140 développeurs. Il est possible de dumper l'ensemble d'une version sous forme d'un fichier aisément parsable automatiquement. Donc is suffit de forcer un tel dump régulièrement (toutes les nuits par exemple) pour sauvegarde.

Au final, Subversion semble avoir tenu toutes ses promesses, qui sont celles d'un système de gestion de configuration destiné à remplacer CVS. Subversion ne rpétend pas révolutionner le monde des SCM, mais il est souple, fiable et puissant, et peut gérer des projets complexes. Multiplateforme et doté d'interfaces graphiques évoluées, il ne lui manque que la fusion avec historique pour se hisser au niveau des meilleurs produits commerciaux.
 
----
 
Gnu Arch est développé sous licence GPL principalement par Tom Lord. La philosophie de Arch diffère fortement de celle de systèmes de gestion de configuration plus traditionnels comme Subversion, du fait qu'il ne gère non pas des versions de fichiers et de hiérarchies de fichiers, mais des "changesets". Les changesets sont assimilables à des patchs sur l'arborescence des fichiers. D'ailleurs les commandes s'appellent mkpatch, dopatch...  
 
Conceptuellement, c'est très intéressant, parce qu'une modification du code d'un projet (un nouveau développement ou une correction par exemple) impacte généralement plusieurs fichiers en même temps. L'ensemble de ces modifications constitue un changeset. Un changeset, qui est une révision dans Arch, correspond donc plus à la pose d'un label dans les SCM traditionnels. Comme tous les changesets sont enregistrés, l'un des avantages de ce système est qu'il est très facile de revenir à des versions précédentes du projet. D'autre part, on ne compare plus des versions de fichiers, mais des changesets.  
Il est possible de repartir d'une version antérieure de la hiérarchie et d'appliquer automatiquement les changesets qui séparent deux révisions du projet. Pour peu que l'on ait bien séparé les corrections de bogues des nouveaux développements, il est ainsi plus facile de reporter les modifications entre branches parallèles.
 
Autre avantage non négligeable d'Arch: le fait que ce soit une base décentralisée. Cela signifie qu'il est possible de récupérer en local une branche de quelqu'un d'autre, de travailler dessus alors qu'on est déconnecté  du réseau (et checkiner les modifs), et plus tard, la personne pourra récupérer ces modifs sans problème. C'est très utile lorsque deux équipes travaillent en parallèle sur des parties de code communes sans être sur le même réseau, ce qui arrive parfois. J'ai eu à affronter ce problème récemment avec ClearCase, et j'ai dû récupérer des modifs via disquette et patcher le code à la main...
Du point de vue de la sécurité, ce système est intéressant car la base est redondante. Vienne un disque dur à rendre l'âme, on peut récupérer toute l'archive à partir du PC d'un autre développeur. Par contre, les modifs complexes non "commitées" ont p-ê tendance à rester plus longtemps en local.
 
Avantages   :
 

• les commit sont atomiques

• la fusion avec historique est gérée.

• la base étant décentralisée, possibilité de travailler tout en étant déconnecté du réseau, les changesets étant appliqués à posteriori.

• capable de gérer efficacement des situations complexes

• import de bases CVS possible (via cscvs)

• les versions sont stockés sous forme de tarballs.

Inconvénients   :
 

• l'inconvénient principal : ne fonctionne que sur les systèmes Posix. Windows semble  exclu d'emblée et l'auteur ne parait pas pressé de s'en soucier. C'est un problème majeur qui fait que l'utilisation d'Arch se limite au monde Unix.  

• jeu de commandes complètement différent de CVS.

• prise en main plus complexe que subversion, et peu d'outil graphique à disposition (Octopy sous KDE).

• performances un peu en retrait

• Arch impose ses conventions sur les noms de fichiers. Pour un nouveau projet, c'est une habitude à prendre, mais pour un projet en cours, c'est rédhibitoire.

• documentation encore un peu à la traine(mais suffisante pour débuter)

Comme on le voit, les idées derrière Arch sont assez originales dans le monde des SCM (quoique darcs va encore plus loin). Tous ces avantages me paraissent conférer à Arch une puissance comparable à celle d'un ClearCase, tout en étant bcp plus simple à administrer (et évidemment infiniment moins cher). Malheureusement, Arch se cantonne pour l'instant au monde Unix, et souffre d'un manque de support par des outils graphiques externes (mais il est facile, comme tout SCM, de l'intégrer à Emacs par exemple).
Je pense que c'est le meilleur choix dans un réseau exclusivement Unix, spécialement sur des projets d'importance. Si le réseau est hétérogène, subversion est la bonne alternative, mais il faudra éviter de multiplier les branches parallèles pour limiter le nombre de merges sans historiques.
Enfin, je signale l'existence d'un projet d'une version décentralisée de subversion, qui nécessite ce dernier, nommée svk.
 
----
 
Les deux outils supportent la notion de trigger/hook, c à d des actions automatiquement déclenchées au moment des opérations de checkin/commit, checkout, etc.
 
A lire aussi :
http://www.dwheeler.com/essays/scm.html
http://better-scm.berlios.de/compa [...] rison.html

Pompé sur slashdot, pour installer BerkeleyDB, Apache, Subversion à partir des sources :
 

 
ps : la version actuelle de subversion est la 1.1.0-rc1.

joli el muchacho, ca mérite qu je prenne le temps pour refaire un peu le premier post pour intégrer tout ca...
 
--> pour arch : bof, le sys de révision utilise une philosophie très similaire dans ue subversion : une révision, c'est l'état du repository a la révision X ...donc là aussi c simplissime de retrouver une version précédente...
--> a noter également que Tigris (l'host de subversion) développe une chiée de clients, dont :  
- un client graphique en C++/Wxwidget (rapidSVN)
- un client graphique en java (g plus le nom en tete)
- un client graphique intégré au shell (tortoiseSVN)
- un plugin Eclipse (sublipse, un bijou )
- une tache Ant (svnant)
- un plugin VisualStudio
- un client genre webSVS
 
ce qui en fait un outil très complet, extremement portable et intégrable... même debian, pourtant pro GNU à mort, passe sous subversion (la nightly de la sarge par ex est dével avec subversion)
 
c un projet ultra dynamique, les ML explosent de commentaires, ca évolue très vite, et proprement...(en tout cas pour svn et subclipse)
 
la doc de svn est également sans commune mesure avec les autres : y'a un livre libre écrit sur le sujet, dont on peut se procurer une version imprimée chez O'reilly...c'est le SVNbook, qui détaille tt le SCM de sa philo à des configs de barbares (hook, server apache, etc...) et est une super référence sur le sujet.
 
Pour le server je nuancerais beaucoup :  
- svnserve : un enfant de 5 ans pourrait monter un repository...ca prend 3 secondes et 2 commandes...pour le gérer avec des utilisateurs, c à peine plus long
- apache + webdav + svn : alors là oui c plus chaud forcément...mais c pas le même usage ...
 
là encore, cette modularité est tt à son honneur...et permet une scalabilité énorme
 
--> pour la version actuelle :  
1.0.6 security fix : la dernière stable
1.1.0-rc1 : rc1 de la future branche stable...
Il faut voir que toute la nébuleuse svn est encore en 1.0.x, donc l'upgrade est périlleux...à voir...
 
pour tes 2 postes néenmoins...j'hésite à faire un topic spécial subversion en plus de celui là...

Tiens, j'ai ajouté une conclusion pour Subversion, je me suis aperçu que j'avais oublié de la mettre.

je sens que je v le faire ce topic subversion et dérivés (surtout qu'il a le vent en poupe ce scm, et encore g oublié des trucs :  
 
on trouve des servers gratos pour y placer ses repositories)

Un post pour présenter rapidement un outil open source que j'ai découvert dans un article du "Dr Dobb's" de ce mois-ci.
 
Ca s'appelle CruiseControl et c'est un framework d'intégration continue qui peut s'interfacer avec un certains nombre de SCM : CVS Perforce, Subversion, ClearCase, SourceSafe, StarTeam.
                                                                                 
 
L'idée de l'intégration continue est une des idées centrales de l'extreme programming, à savoir que tous les développeurs travaillent en permanence sur la dernière version intégrée et testée du projet, mais que le cycle d'intégration et test se fait non plus sur une base de 15 jours (voire plus), mais sur une base journalière. Les développeurs intègrent eux-mêmes leurs propres modifications du code et le build complet et le passage de l'intégralité des tests est quotidien (il est lancé automatiquement chaque nuit, par ex.). Notons que ce cycle est appliqué depuis des années chez Microsoft par exemple.
 
Pour automatiser ce processus, CruiseControl interroge la base du SCM pour déterminer si un fichier a changé, et invoque l'outil Ant pour lancer un build complet et le passage automatique des tests de non-régression. Ensuite il renvoie une page HTML de résultats, pose un label/tag sur la version en cas de succès et envoie un email aux développeurs avec les résultats.
 
Ainsi, dans ce cycle d'intégration continue, une fois qu'il a fini une tâche, Paul intègre lui-même ses modifications dans le code existant (qui date de la nuit dernière) et checkine. Sur sa machine, CruiseControl va lancer en fin de journée un cycle de build & de test complet. Le lendemain, Paul va recevoir un mail l'informant du succès ou de l'échec du cycle nocturne.  
En cas d'échec, il va devoir revoir sa copie pour corriger le problème.  
En cas de succès, CruiseControl va poser un label sur la version nouvellement créée, envoyer un mail d'information aux autres membres de l'équipe et peut même automatiquement déclencher un nouveau build complet sur leurs machines, qui sera alors à jour le lendemain (si la nuit est suffisamment longue pour le cycle build/tests sur la machine de Paul, puis build pour les autres machines).
 
Ainsi, à part l'opération de fusion, qui est réalisée par les développeurs eux-mêmes, CruiseControl prend en charge l'intégralité du travail d'intégration.
 
Comme expliqué dans l'article, le processus d'intégration continue se basant essentiellement sur des tests automatiques pour valider les versions intermédiaires (ce qui n'exclut en rien une phase de validation du produit final), il est crucial que ceux-ci soient à jour et que leur couverture soit aussi importante que possible. La tâche d'intégration étant réduite à sa plus simple expression, la charge de travail est reportée sur la qualité des tests et la non-régression. De plus, les conflits apparaissent plus tôt dans le processus, et sont bcp plus faciles à identifer, puisqu'ils sont résolus un à un, et non après de multiples fusions comme c'est souvent le cas lors d'une intégration à longue échéance.
L'utilisation d'un framework de test (JUnit, CppUnit ou d'autres par exemple) peut aider dans l'écriture de tests. Pour les tests d'IHM sous Windows, certains peuvent être automatisés grâce à AutoIt ou des outils commerciaux.
 
Enfin, l'article parle plus spécifiquement de la version pour .NET, CruiseControl.NET. Il recommande son utilisation avec un autre outil gratuit, FxCop qui vérifie la conformance du code avec les conventions recommandées par les .NET Framework design guidelines, ainsi qu'un outil de couverture de code peu cher pour Java et C# nommé Clover.
 
Voici deux retours d'expérience en intégration continue avec CruiseControl:
http://www.developertesting.com/de [...] 00023.html
http://www.sys-con.com/story/?storyid=37461&DE=1
Un article qui détaille l'installation du framework CruiseControl:
http://www.theserverside.net/artic [...] ntegration

Bonjour à tous,
j'étais en train d'écrire un trop long post pour vous expliquer mon problème et en retestant les commandes pour les copier coller ici, j'ai fait une "mauvaise manip" par rapport à ce que je faisait avant, et là ... ça marche
 
Donc, je poste quand même ma question et sa réponse pour ceux qui comme moi on un peu de mal...
La question :

 
la réponse :
Il ne faut pas faire de checkout sur le repertoire /usr, au final la manip est la suivante :

 
Voila, pour moi ça marche, mais ce n'est peut être pas la bonne façon de procéder, donc n'hésitez pas à faire vos commentaires dessus

sur ce topic de l33t

too

Je vois que ce topic n'est pas fréquenté assidument, mais je tente ma chance tout de même
 
J'ai un gros problème avec SVN.
Nous sommes actuellement en train de tester SVN pour remplacer VSS, les premiers tests se sont déroulés sur le réseau local, jusque ici tout va bien.
Mais comme nous avons des dev à distance, j'ai voulu tester un peu la chose à distance  au travers de notre VPN, et la, les choses se corsent !
 
En effet en étant connecté à distance j'ai pu locker et faire des commits sur un fichier qui était déja locké par un autre utilisateur (sans avoir l'avertissement que subversion donne normalement dans ce cas et qui fonctionnait bien sur le réseau local).
 
Pour ce test subversion était utilisé via http avec webdav, je vais essayer en ne passant pas par http pour voir, mais cela me semble quand même très bizarre !
 

bon alors, 2 - 3 questions si jamais y'a qqun avec un peu d'experience d'admin subversion qui passe dans le coin:
 
* "meilleur" moyen pour "fermer" une branche ? jouer sur les permissions, jouer avec un pre-commit hook ?
 
* je suis sur le point de completement restructurer notre repo, mais idéalement les URLs courantes devraient rester valides, idéalement^2 rediriger vers les nouvelles... y'a un moyen gérable ou j'oublie ? (sachant que y'a facile une 50aine de projets dans le repo...)

Ne rien faire (fermeture informelle), ou bien alors créer un tag correspondant à la release finale et supprimer la branche du repo (ça va juste la dégager dans la dernière révision et les suivantes, l'historique sera toujours là pour qui sait où le chercher, et naturellement via le tag)

Ptet à coups d'url rewriting dans apache, mais franchement ça risque d'être très très moyen. Je suggérerais plutôt de restructurer et de forcer tout le monde à migrer, si applicable avec un switch --relocate

en fait un de mes probs c'est que ça devient le bordel avec toutes les branches (i.e en navigant dans le repo avec un browser web) et j'suis tenté de la deleter.. la release finale est faite et taggée. Mais c'est vrai que l'historique reste la en fait, chuis con
 

en fait c'est pas tellement pour le developement en cours que pour le fait que je vais avoir des tonnes d'url invalides un peu partout
(notamment les pom maven des versions des projets releasés avec la restructuration)

Faut pas hésiter à deleter de toute façon, si tu vas pas réécrire le dump tout l'historique va rester, et si besoin tu peux restaurer tout le bordel (avec un truc genre svn copy -rladernièrebonnerévision chemin0 chemin1

J'vois pas pourquoi tu voudrais taper dans les pom mavens qui sont dans svn, donc j'peux rien dire là dessus

pour récuperer la revision/le tag correspondant a la release (le pom étant dans le jar releasé, et les urls du scm etant dans le pom, justement - avec le tag qui va bien, ajusté par le plugin release)

bump pour dire quand même qu'il y a maintenant des scm avec nombre d'avantages (et peu d'inconvénients) sur un Subversion ou un Perforce (sans même parler d'un CVS ou un SourceSafe ) et avec des services d'hosting gratuits (source + issues + wiki + dox + ..., à la sourceforge mais en moins moche et moins lent, comme Google Code en fait) correspondants franchement sympas: git (et github), mercurial (et bitbucket), bazaar (et launchpad?)