Ce qui manque le plus a SVN actuellement c'est le la mémoire des merge
Si on travaille sur 2 branches en parallèle, svn ne garde pas de trace des derniers merge et on peut se retrouver avec le même patch appliqué plusieurs fois en des endroits différents du code.
Pour contourner, il faut donc retenir soi même les versions correspondant au dernier merge et n'appliquer que les patchs depuis cette version.
La mémoire de merge est prévue pour la 2.0 je crois.
Un avantage de SVN est qu'il s'intègre bien avec des outils de suivi des demandes de changement (issue tracking).
De même sa gestion des révisions est particulièrement astucieuse et efficiente.
Svn historise le projet et lui affecte un numéro de révision.
Chaque modification de fichier créé une nouvelle configuration (révision) mais tout se passe comme si tous les fichiers et répertoires inchangés etaient pointés par des liens symboliques et seul les fichiers modifié sont vraiment nouveaux . L'algorithme permet donc de créer un nouvelle branche de dev ou de répérer configuration (release) en O(n) à comparer à la lenteur d'autres outils y compris propriétaires comme perforce ou clearcase.
Pour l'aspect distribué, il est prévu à terme d'en produire une version distribuée.
On peut toujours développer dans son coin mais on ne peut pas historiser de version intermédiaire. Ca n'est vraiment un inconvénient que lorsque qu'on veut impléménter plusieurs changements à la suite et les livrer en un bloc.
De même on peut toujours revenir au code initial en local sans accès serveur (svn revert)
Si on veut vraiment une version distribuée, on dispose de svk.
par contre il faut aimer hacker le perl si on veut contribuer
[^] # Re: étude comparative
Posté par golum . En réponse au journal Gestionnaire de versions. Évalué à 2.
Si on travaille sur 2 branches en parallèle, svn ne garde pas de trace des derniers merge et on peut se retrouver avec le même patch appliqué plusieurs fois en des endroits différents du code.
Pour contourner, il faut donc retenir soi même les versions correspondant au dernier merge et n'appliquer que les patchs depuis cette version.
La mémoire de merge est prévue pour la 2.0 je crois.
Un avantage de SVN est qu'il s'intègre bien avec des outils de suivi des demandes de changement (issue tracking).
De même sa gestion des révisions est particulièrement astucieuse et efficiente.
Svn historise le projet et lui affecte un numéro de révision.
Chaque modification de fichier créé une nouvelle configuration (révision) mais tout se passe comme si tous les fichiers et répertoires inchangés etaient pointés par des liens symboliques et seul les fichiers modifié sont vraiment nouveaux . L'algorithme permet donc de créer un nouvelle branche de dev ou de répérer configuration (release) en O(n) à comparer à la lenteur d'autres outils y compris propriétaires comme perforce ou clearcase.
Pour l'aspect distribué, il est prévu à terme d'en produire une version distribuée.
On peut toujours développer dans son coin mais on ne peut pas historiser de version intermédiaire. Ca n'est vraiment un inconvénient que lorsque qu'on veut impléménter plusieurs changements à la suite et les livrer en un bloc.
De même on peut toujours revenir au code initial en local sans accès serveur (svn revert)
Si on veut vraiment une version distribuée, on dispose de svk.
par contre il faut aimer hacker le perl si on veut contribuer