Existe-t-il un moyen de migrer SourceSafe avec HISTORY vers SVN?

Question

Existe-t-il un moyen de migrer SourceSafe avec HISTORY vers un SVN?

Idéalement, j'aimerais utiliser VisualSVN Server, mais je ne veux pas vraiment perdre mon historique SourceSafe. Si je dois le faire, je le ferai cependant.

Answer 1

Il y a longtemps (apparemment), j'ai tenté de migrer une base de données SourceSafe vers Subversion à l'aide de vss2svn . , mais a finalement abandonné. Il y avait plusieurs problèmes, IIRC:

• vous devez vous assurer que la base de données SS est cohérente (par exemple, Analyze ne trouve aucun problème ou est capable de le résoudre).
• la migration de la base de données a pris beaucoup de temps, car elle était assez grosse.
• Enfin, la migration a échoué en raison de problèmes liés à l'analyse des dates. Je ne pouvais pas trouver la raison du problème, mais je suppose que c'était dû au fait que nous utilisions le format de date JJ.MM.AAAA au lieu du format de date américain.

Nous avons donc finalement décidé de conserver la base de données SourceSafe intacte (en lecture seule) et de simplement migrer la version actuelle vers Subversion. Jusqu'à présent, nous avons rarement eu à revenir à SourceSafe pour vérifier quelque chose.

J'espère que cela vous aidera.

BTW: peu importe que vous utilisiez VisualSVN Server ou subversion directement (svnserver). Le format du référentiel est le même dans les deux cas.

Answer 2

Essayez le script vss2svn .

Ou le projet vss2svn .

Answer 3

J'ai converti avec succès notre base de données VSS, y compris l'historique. Je blogue sur l'expérience < strong> here. Le surlignage de la conversion est:

"Tous les outils de conversion ont également demandé que la base de données VSS source soit exempte de corruption avant la conversion. Cela s'est avéré beaucoup plus difficile et prend beaucoup de temps que vous ne le pensez. L'exécution de l'outil VSS Analyze sur une copie de la base de données a montré des centaines de corruptions et ne pourrait pas aboutir sans un filtrage bleu de l'ordinateur sur lequel il était exécuté.

Pour éviter ce problème, nous avons réduit la base de données de copie en supprimant les répertoires que nous ne voulions pas convertir. Malheureusement, VSS signalera chaque corruption au cours du processus de suppression, entraînant des centaines de boîtes de message sur lesquelles l'utilisateur doit cliquer sans réfléchir pour que le processus se poursuive.

Une fois ce point atteint, nous avons utilisé l'outil VSS2SVN pour créer des fichiers de vidage importés dans Subversion. "

Answer 4

Nous avons utilisé l'importateur Polarion SVN pour migrer de VSS vers SVN avec un historique complet. .

Answer 5

Oui, utilisez le projet VSS2SVN sur Codeplex . Je l'ai mis à jour pour qu'il conserve l'historique, les commentaires, les propriétés de l'auteur et de la date lors de la migration vers SVN. Cela prend un peu plus de temps, mais je ne pense pas que cela compte, car ce n’est pas quelque chose que vous faites tous les jours.

Il offre également la possibilité de mettre à jour le référentiel avec les fichiers de VSS après une certaine date, afin que vous puissiez mettre à jour un vidage initial ultérieurement.

Answer 6

Au sein de mon entreprise, j'ai essayé à plusieurs reprises de migrer un (grand) référentiel SourceSafe vers Subversion avec vss2svn. J'ai même provoqué une petite contribution concernant le support de page de code (nous avions des noms de fichiers en grec). Si je me souviens bien (cela s’est passé au printemps dernier; c’est-à-dire en 2009), notre principal problème (celui qui nous a finalement fait rejeter la migration) était le blocage des fichiers supprimés de manière permanente qui étaient réticulés / déplacés entre les parties souhaitées et non souhaitées du référentiel. la migration.

Ma suggestion: si vous ne pouvez pas le faire dans un référentiel entièrement Analysé , ne perdez pas plus de temps. Tracez simplement une ligne et commencez avec un nouveau référentiel de subversion.

Remarque: la suppression définitive d'un fichier dans SourceSafe le rend totalement irrécupérable, ce qui est tout à fait incompatible avec les systèmes de contrôle de source de type CVS / SVN (et, je suppose, avec d'autres systèmes de contrôle de source également.)

.

Answer 7

Mon entreprise a développé un outil de migration Source Safe to Subversion: http://www.abstrakti.com/Products/Krepost

Cet outil a été développé après avoir rencontré des problèmes avec tous les autres outils, lors de la migration du référentiel d'un client. En outre, il s'agit du seul outil capable d'importer des étiquettes SourceSafe dans SVN. En outre, il est capable de gérer la plupart des corruptions du référentiel SourceSafe et offre une migration simple pour les utilisateurs qui ne veulent pas passer quelques jours à déboguer du code C #.

Faites-moi savoir si vous avez des problèmes, je serai heureux de vous aider.

Eric.

Answer 8

J'ai réussi à faire migrer plusieurs référentiels sécurisés vers des sources vers SVN à l'aide du script vss2svn . Mes suggestions sont, faites-le par petits morceaux - nous avons eu beaucoup de petits projets et quelques projets parallèles, qui ont tous réussi à être transférés avec succès à SVN.

J'ai eu quelques problèmes:

• Les fichiers volumineux n'ont pas pu être écrits au format de fichier de vidage SVN, j'ai soumis un correctif pour le faire fonctionner. Je pense que quelqu'un l'a écrit un peu plus sophistiqué une fois que j'ai terminé.
• La structure du répertoire racine n'a pas été copiée correctement. Le référentiel VSS était organisé en tant que $ / client / projet. Le référentiel svn a finalement été organisé en svn: // server / randomdirectory / anotherrandomdirectory / client / project. J'ai donc corrigé ces problèmes en éditant le fichier de vidage avant de l'importer (je pense qu'il s'agissait de find, remplacer "/ randomdirectory 'with' '.