Subversion est un système de gestion de version, qui a été développé dès 2000 par CollabNet dans le but de remplacer CVS comme logiciel standard de contrôle de révision dans le monde du libre. La version 1.0 est sortie au terme de 5 ans de conception et de développement et regroupe maintenant une communauté très active. La majorité des projets libres qui utilisaient CVS sont passés à SVN au fil du temps.
SVN est sous licence BSD. L'équipe ne propose pas de binaires de Subversion par défaut aussi faut-il parfois un peu de temps pour voir arriver la dernière version sur son OS. Subversion est disponible sous GNU/Linux, NetBSD, FreeBSD, OpenBSD, Solaris, MacOSx, IBM i5/OS et l'autre. Deuxième version de l'année pour la branche 1.4.x, cette version est une simple version de correction qui propose une mise à jour de chaque élément de la distribution (client, serveur, etc.). La liste complète des modifications est visible dans le fichier CHANGES.
En plus des correctifs, on notera :
- une mise à jour des langues Chinois simplifié, Japonais et Norvégien ;
- "make svnserveautocheck" permet de tester les cibles ;
- la correction d'erreurs dans les bindings javahl, SWIG/perl, SWIG/python et SWIG/ruby.
Aller plus loin
- Subversion (4 clics)
- Les changements (3 clics)
- La page de téléchargements (6 clics)
- Les notes de version de la série 1.4.x (5 clics)
- DLFP: Subversion 1.4.0 est disponible (7 clics)
# "l'autre"
Posté par Guillaume Ceccarelli . Évalué à 8.
[^] # Re: "l'autre"
Posté par Olivier Serve (site web personnel) . Évalué à 5.
/o/ ===>[]
[^] # Re: "l'autre"
Posté par Mickaël Sibelle (site web personnel) . Évalué à -2.
[^] # Re: "l'autre"
Posté par Anonyme . Évalué à 9.
[^] # Re: "l'autre"
Posté par clem . Évalué à 0.
# Mercurial/SVN
Posté par alt3 (site web personnel) . Évalué à 3.
[^] # Re: Mercurial/SVN
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
[^] # Re: Mercurial/SVN
Posté par Bozo_le_clown . Évalué à 4.
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-se(...)
Qui se résoud en attendant avec ca
http://www.orcaware.com/svn/wiki/Svnmerge.py
[^] # Re: Mercurial/SVN
Posté par Bozo_le_clown . Évalué à 4.
http://subversion.tigris.org/merge-tracking/
Plus de détail sur la problématique dans les cas d'utilisation
http://subversion.tigris.org/merge-tracking/requirements.htm(...)
[^] # Re: Mercurial/SVN
Posté par Bozo_le_clown . Évalué à 2.
http://subversion.tigris.org/issues/show_bug.cgi?id=695
# Clearcase
Posté par tuiu pol . Évalué à 2.
[^] # Re: Clearcase
Posté par Anthony Jaguenaud . Évalué à 2.
Qu'est-ce que subversion a de mieux ?
Personellement, je bosse avec clearcase, et je ne trouve pas subversion particulièrement sexy.
[^] # Re: Clearcase
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: Clearcase
Posté par Anthony Jaguenaud . Évalué à 2.
L'utilisation de vue avec montage nfs de l'arbo, sans rapatrier l'ensemble du projet, ...
Ma vision, probablement fausse de svn, c'est qu'on récupère un projet complet, ensuite, on commit tous les fichiers qui ont bougé.
Peut-on reserver un fichier qu'on checkout ? Enfin, ce genre de chose.
J'aimerais avoir un vrai comparatif, pas des pseudo argument chez moi, j'utiliserai svn mais chez un client ? Quels sont les avantages de svn s'il y en a ?
[^] # Re: Clearcase
Posté par Bozo_le_clown . Évalué à 5.
vue dynamique:
SVN ne fournit que l'équivalent des vues snapshots et pas de vues dynamiques.
Avantage:
pas besoin de charger les données
Inconvénient:
Mode connecté => dépend du bon état du réseau, pas de possibilité de travailler hors ligne, simple point of failure si le serveur de registre ou de vob tombe
Vue snapshot,dynamique vs workspace SVN.:
Ne fonctionne que dans une architecture réseau commune (droits à allouer sur le postes, création d'un compte service dans le domaine.
Performance dégradées à distance au point que le multisite ou les clients Web deviennent incontournables.
Avec SVN derrière un frontend Apache pas de pb de performance
Solution IBM pour la 7.0 => CCRC qui revient à fournir le modèle SVN .
Obligation d'administrer les vues car lors des co le serveur de registres garde la trace des fichiers réservés.
Il faut purger régulièrement de registres les vues qui ne sont plus utilisées.
Avec SVN pas de trace. Si un fichier est locké par un utilisateur on peut forcer le unlock et on a pas de trace
Gestion des licences:
coût des licences et simple point of failure lorsque le serveur est out.
Modèle de concurrence:
obligation de réserver un fichier (même en unreserved ) avant de le modifier pour CC.
SVN : possibilité de choisir pour certain fichiers un fonctionnement avec un lock exclusif (fichier images par exemple) et modifiication sans réserver les fichiers pours les autres.
Gestion des droits administrateurs
Avec CC lié à l'OS => nécessite de contacter les admins pour créer un compte chaque fois qu'on veut ajouter un nouvel utilsateur (pour compliquer le tout obligation d'avoir le même compte sur tous les OS créer le compte dasn Active Dirctory et le recréer sur le serveurs Linux)
Multisite:
Mise en ouevre complexe et nécessaire à cause des perfs lorsque 2 réseaux d'entreprise sont différent et distants.
Avec SVN l'approche centarlisée convient et l'administation derrière Apache permet de ne pas être liée à l'archietcture du réseau (un login et un pw suffisent). IBM propose le CCRC pour contourne le pb dans la 7.0
Merge et intégration
Avantage à CC qui propose depuis tjs le merge tracking (hyperlien de merge), des assistants de merge pour une arborescence complètes et des interfaces de merges adaptés à des fichiers autres que seulement du texte (XML, modèles Rose, RSM, , word, ...)
Triggers
Placés du coté des clients avec CC suaf depuis la 7.0 avec le CCRC.
permet d'intrecepter plus d'opération mais necessite de les déployer sur chacun des clients et de les porter sur tous le OS.
Fabrication:
Cleamake permet le partage d'objets dérivés et l'audit de fabrication
Pb aujourd'hui ANT ou compil incrémentale pour Java
Gestion des changement
Clearcase de bas n'a pas de commit atomique (changeset)
=> obligation d'utiliser UCM pour s'interconnecter avec un outils de change/bug tracking.
Pas de gestion des composants à la UCM pour SVN
....
[^] # Re: Clearcase
Posté par Bozo_le_clown . Évalué à 2.
Obligation de faire des montages NFS pour bosser entre les stations de travail sous Linux et les serveurs même avec des vues snapshots alors que CCFS uitilse juste du RPC sous Windows. Intéressant sur des sites distants.
Pour accéder à l' API on a le choix entre COM/DCOM (Windows only) , ccperl (don't feed the troll) ou le parsing du CLI. à comparer avec l'API de SVN et ses 2 couches et la facilité de créer des wrappers (python, SVNkit, .....)
Allez je vais arrêter là.
[^] # Re: Clearcase
Posté par tuiu pol . Évalué à 1.
Mais sinon c'est rigolo de voir que ceux qui l'utilisent sont près à mourir plutôt que passer à autre chose. J'ai du louper un truc à l'époque !
[^] # Re: Clearcase
Posté par Anthony Jaguenaud . Évalué à 3.
-- 'Pourquoi c'est mieux ?'
-- 'Ouarff le nul, il sait même pas que c'est mieux'
-- 'Explique moi ?'
-- 'Hihihi, il sais pas que c'est libre'
-- 'Oui, enfin, t'a un vrai argument ?'
-- 'Ouarff il est nul, il sait pas que c'est mieux...'
Bon, je ne suis pas sur, mais il me semblait avoir quitté la maternelle depuis un moment, alors soit quelqu'un sait faire une comparaison ou bien je ne serais pas plus avancé. Mais les remarque qui servent à rien, ne font, amha, pas avancer le shimlblik.
[^] # Re: Clearcase
Posté par Anthony Jaguenaud . Évalué à 4.
http://pipoware.free.fr/wordpress/?p=154
http://better-scm.berlios.de/comparison/comparison.html
il y en a certainement d'autre.
[^] # Re: Clearcase
Posté par tuiu pol . Évalué à 2.
Non, par contre, j'ai constaté à l'utilisation, que je ne trouvais AUCUN argument en faveur d'une utilisation de Clearcase tout simplement. Et on ne peux même pas se retrancher derrière le parapluie "on a IBM derrière", il m'est arrivé de m'entendre répondre que le bug qui nous empêchait de produire serait corrigé .. dans 6 mois ! C'est pourquoi, alors qu'aujourd'hui je ne l'utilise plus, je plains ceux qui sont obligés de se le farcir.
[^] # Re: Clearcase
Posté par Bozo_le_clown . Évalué à 2.
A partir du moment où tu as toutes les versions de fichiers d'un projet tu peux tjs les récupérer par script une par une et alimenter un dépôt d'un autre gestionnaire de version
[^] # Re: Clearcase
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Clearcase
Posté par Bozo_le_clown . Évalué à 2.
Avec un cleartool find bien paramétré tu peux récupèrer l'historique de tous les éléments, répertoires y compris.
Tu peux aussi te baser sur le clearexport_ccase
ou encore partir de la racine la racine de ta vob, récupérer son arbre de version, et descendre récursivement dans chacune des versions de répertoires.
En revanche avant de remonter ces versions tu dois appliquer un traitement pour reconstituer des baselines ou des révisions de façon cohérente .
Sans ce traitement tu risques de te retrouver avec un repository incompréhensible car CC pratique le versionning au niveau des elts et SVN au niveau de l'arborescence entière. Un fichier ou répertoire regroupe tout son historique dans l'arbre de version de l'elt auquel il est associé alors qu'avec SVN modifier une version de fichier revient à créer une nouvelle configuration i.e une nouvelle révision de toute ton arborescence.
Il faut donc bien réfléchir à la stratégie d'import.
Par exemple regrouper toutes les versions d'arborescence qui ont tiré la branche v1.0 sous CC dans le répertoire /branches/v1.0/mon_projet/
et les baselines labelllisées sous /label/ (exemple /label/V1.0-r1/mon_projet/)
Sinon si tu remontes chronologiquement, tu va te retrouver avec des révisions qui ne seront pas logiquement liées entre elles (genre la révision 43 qui correspond à la release 2.3 sera suivie par la révision 44 qui correspond au dernier patch de la 1.5 avec des. On récupère 2 arboresence mon_projet mais pas moyen de voir à quoi elle corresponde.
Si tu remontes sans traitement préalable c'est encore pire, tu auras un historique du genre
rev 1:
/src
rev 2:
/src
/src/package1
rev 3:
/src
/src/package1
/src
/src/package2
rev 4:
/src
/src/package1/f1.java (version /main/1 de f1.java)
/src
/src/package2
rev 5:
/src
/src/package1/f1.java (version /main/v0.1/1 de f1.java)
/src
/src/package2
/src
/src/package1/f1.java (version /main/v0.1/1 de f1.java)
/src
/src/package2/f2.java (version /main/1 de f2.java qui n'a jamais été associé à f1.java/main/v0.1/1 dans aucune vue)
Bref tu auras l'historique des fichiers mais aucune baseline
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.