Стратегия TFS для перемещения большого количества проектов из Source Safe

Question

Компания, в которой я работаю, имеет более 1000 приложений, которые мы поддерживаем. Многие из них используются в старых технологиях, таких как VB6, или в плохих технологиях (Access).

Мы надеемся отойти от Source Safe. У нас запущен TFS, и мы перемещаем наши проекты dot.net в TFS. Другие проекты не интегрируются с TFS и не нуждаются в портале или каких-либо других функциях TFS (кроме контроля версий).

Я обеспокоен выходом из других проектов в Source Safe из-за ненадежности продукта.

Насколько я вижу, есть два варианта:

1) Создайте пустой проект в TFS с именем «VB6» (например). Разветвите его для каждого приложения VB6, которое находится в VSS. Это поместит все приложения VB6 в эту подпапку. Таким образом, все приложения могут быть в TFS.

2) Поместить проекты dot net в TFS. Создайте CVSNT-репозиторий и поместите туда все другие проекты VSS.

3) Поместить проекты dot net в TFS. Оставьте все остальные проекты в VSS. Запустите еженедельное сжатие и исправление всех баз данных VSS.

Какой вариант люди считают лучшим? Кто-нибудь еще был в подобной ситуации?

Answer 1

Ни один из трех вариантов не имеет смысла для меня. Если вы хотите отойти от SourceSafe и уже решили перейти на TFS (по крайней мере, для своих проектов .NET), то, по сути, вы спрашиваете, есть ли хороший способ перенести источник для 1000 старые технологии приложений для TFS?

Я рекомендую просто использовать Source Control Explorer в качестве клиента SCC для TFS. Он работает аналогично графическому интерфейсу SourceSafe. Любая причина, которая не будет работать?

Answer 2

Вопрос ИМХО в вашем определении "Проект". Командный проект - это контейнер высокого уровня, используемый для определения процессов и изоляции. Нет причин отказываться от командного проекта VB6 со сложным исходным деревом. Для каждого приложения VB6 нет необходимости создавать фактические значения «ветвей» (в ветвлении и слиянии). Точно такая же структура папок у вас в SCC.

Так что, по сути, я не вижу никаких причин не делать ваш первый вариант - просто не беспокойтесь о накладных расходах ветвления (если только у вас нет реальной необходимости в этом)

Answer 3

Вариант 3 кажется наиболее экономичной ставкой в ​​такой ситуации, если предположить, что хранилища VSS остаются размером <1-2 ГБ (насколько я понимаю, они становятся более подверженными коррупции, когда становятся больше - это уходя из памяти, правда, так что я могу ошибаться). Храните резервную копию VSS в физически отдельном месте для страховки, а в остальном продолжайте работать как есть. Относительно небольшая рентабельность инвестиций в движение, как вы описали в общем случае. </p>

Answer 4

Git> TFS, используйте вместо этого.