- Subversion n'est pas forcément très stable (corruption de la base de données, rare mais possible), il est lui aussi assez jeune. Arch n'utilise au final que tar+gzip pour stocker les fichiers, ce qui facilite un éventuel sauvetage des données ou leur transfert vers une autre machine (plus lourd avec Subversion car si on change d'architecture - ou parfois même de version - on ne peut pas se contenter de copier la base, il faut l'exporter et la réimporter).
- Arch supporte très bien les référentiels centralisés (un petit coup de tla-pqm par exemple), et permet plus de flexibilité dans les autres cas, qui deviennent plus courants (équipe offshore qui ne travaille pas exactement pareil, par exemple).
Ceci dit, il est clair que Arch a besoin d'améliorer sa documentation et ses interfaces graphiques (il y en a en cours de développement). Mais Arch n'a pas les miyons de Subversion, donc ça prend plus de temps.
[^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 2.
- Subversion n'est pas forcément très stable (corruption de la base de données, rare mais possible), il est lui aussi assez jeune. Arch n'utilise au final que tar+gzip pour stocker les fichiers, ce qui facilite un éventuel sauvetage des données ou leur transfert vers une autre machine (plus lourd avec Subversion car si on change d'architecture - ou parfois même de version - on ne peut pas se contenter de copier la base, il faut l'exporter et la réimporter).
- Arch supporte très bien les référentiels centralisés (un petit coup de tla-pqm par exemple), et permet plus de flexibilité dans les autres cas, qui deviennent plus courants (équipe offshore qui ne travaille pas exactement pareil, par exemple).
Ceci dit, il est clair que Arch a besoin d'améliorer sa documentation et ses interfaces graphiques (il y en a en cours de développement). Mais Arch n'a pas les miyons de Subversion, donc ça prend plus de temps.