Quelle peut être la taille d’une base de données Sourcesafe avant les problèmes & # 8221; survenir?

Question

Nous utilisons SourceSafe 6.0d et avons une base de données d’environ 1,6 Go. Nous n’avons pas encore eu de problèmes, et il n’est pas prévu de modifier les programmes de contrôle de source pour le moment, mais quelle peut être l’importance de la base de données SourceSafe avant qu’elle ne devienne un problème?

Merci

Answer 1

Exécutez-vous l’utilitaire ssarchive intégré pour effectuer des sauvegardes? Si tel est le cas, 2 Go est la taille maximale pouvant être restaurée. ( http: // social.msdn.microsoft.com/Forums/en-US/vssourcecontrol/thread/6e01e116-06fe-4621-abd9-ceb8e349f884/ )

NOTE: le programme ssarchive ne vous dira pas ceci; c'est simplement que si vous essayez de restaurer une base de données de plus de 2 Go, cela échouera. Il faut se méfier! Tous ces types qui vous disent qu’ils fonctionnent bien avec une base de données plus grande utilisent un autre programme d’archivage ou n’ont pas testé la fonctionnalité de restauration.

Answer 2

J'ai des problèmes avec VSS qui démarrent à 1,5-2,0 giga

.

La méta-réponse est, ne l'utilisez pas. Le SSV est bien inférieur à une demi-douzaine de solutions de rechange à portée de main. Une partie du contrôle de source est supposée assurer l'intégrité de votre référentiel. Si l’une des hypothèses fondamentales de votre outil de contrôle de source est que vous ne savez jamais quand il va commencer à dégrader l’intégrité des données, vous disposez alors d’un outil qui invalide son propre objectif.

Je n'ai jamais vu un éditeur de logiciels professionnel utiliser VSS depuis presque une décennie.

Answer 3

1 octet!

: -)

Désolé, mec, vous m'avez préparé.

Answer 4

J'ai en fait une base de données vss d’environ 40 Go. Je ne le recommande pas, mais c'est possible. Vraiment, plus vous le laissez aller, plus vous jouez avec le feu. J'ai entendu parler de cas où la base de données était corrompue et où les éléments du contrôle de code source étaient irrécupérables. Je voudrais certainement le sauvegarder quotidiennement et commencer à chercher à changer les systèmes de contrôle de source. Ayant été dans la position du type qu’ils appellent en cas d’échec, je peux vous dire que cela commencera vraiment à devenir stressant lorsque vous réaliserez qu’il pourrait tout simplement baisser et ne jamais revenir.

Answer 5

Étant donné le nombre de problèmes que SourceSafe peut générer par lui-même, je dirais que la taille doit être dans la catégorie "Présent sur le disque". pour qu'il développe des problèmes.

Answer 6

J'ai administré une base de données VSS plus de deux fois cette taille. Tant que vous êtes vigilant dans l'exécution de Analyser , ça devrait aller.

Answer 7

Sourcesafe recommande de 3 à 5 Go avec un "ne jamais dépasser 13G".

Dans la pratique, cependant, nous avons plus de 20G et semble fonctionner correctement.

Plus vous grossissez, Analyze trouve de plus en plus de problèmes, notamment des fichiers perdus, etc.

EDIT: Voici le mot officiel: http: //msdn.microsoft.com/en-us/library/bb509342(VS.80).aspx

Answer 8

J'ai constaté que Analyze / Fix commençait à devenir lent à environ 2G sur un serveur raisonnablement puissant. Nous exécutons Analyze une fois par mois sur des bases de données utilisées par une vingtaine de développeurs. L’utilitaire trouve des solutions occasionnelles, mais son utilisation réelle a été fondamentalement sans problèmes pendant des années sur mon lieu de travail.

Selon Microsoft, l’essentiel est de ne jamais manquer d’espace disque, quelle que soit la taille de la base de données.

http://msdn.microsoft.com/ en-us / library / bb509342 (VS.80) .aspx

citation: Ne laissez pas Visual SourceSafe ou l'outil Analyser manquer d'espace disque pendant son exécution. Manquer d’espace disque au milieu d’une opération complexe peut gravement endommager la base de données