Альтернатива SVN для альтернативного сервера Team Foundation 2012

В настоящее время мы используем SVN для нашего источника управления. Из-за дополнительных функций и интеграции в среду разработки мы хотели бы перейти на TFS 2012.

У нас много запущенных порталов, которые встроены в asp.net. В нашем портале мы используем множество стандартных компонентов. В настоящее время все порталы используют одну и ту же базу кода. Это означает, что всякий раз, когда мы меняем что-то в общей кодовой базе, он (всякий раз, когда публикуется портал) автоматически распространяется. Мы очень привыкли к этому способу работы, и мы знаем, что существует риск нарушения кода на других порталах. Хотя публикация изменений во всех других порталах обойдется дороже на много времени. Поэтому для этого мы используем внешние элементы в SVN.

Мне бы очень хотелось, чтобы эта функция работала и работала. Поэтому мой вопрос заключается в том, есть ли способ создать внешнюю подобную систему в SVN или есть действительно хороший способ, который работает так же эффективно, чтобы заменить эту функциональность.

Ответ 1

Есть пара предложений в Руководство по вставке и объединению сервера Visual Studio Team Foundation.

Если вы загрузите пакет "Все" и загляните в "Все руководства" zip и прочитайте "Расширенное руководство по управлению версиями".

Страницы 5-19 (Версия 2.1) обложка "Управление совместно используемыми ресурсами", там много, и суммирование всего этого на Stack Overflow, вероятно, сделает Ranger несправедливостью, поэтому я просто укажу вам там.

Ответ 2

Нижняя строка: TFS не имеет эквивалента "svn: externals".

Общий доступ к кодам - это BAD и приводит к дублированию кода, а не к повторному использованию кода. Вместо этого зависеть от скомпилированного кода.

Вы должны зависеть только от "вывода" разделяемой библиотеки, а не от исходных файлов. Что касается сценариев, я не могу думать о каких-либо сценариях, где желательно делиться исходными файлами между продуктами/решениями.

Причина заключается в том, что вещи могут стать сложными громоздкими очень быстро. Что делать, если у вас есть переход, чем один, зависящий от общей библиотеки, которые все изменяют на один и тот же код, и они чередуются друг с другом. Единственный путь - начать разветвление вашего общего кода на другие проекты, которые теперь добавляют уровень сложности и интеграции, которые никогда не будут обработаны в долгосрочной перспективе, и вы получите три или более версии одной и той же базы кода время.

Что вам нужно сделать, это иметь один основной компонент, который изменяется и создается для создания вывода. Затем этот вывод можно по требованию в других проектах, которые зависят от этих изменений или нет. Это приводит к меньшему количеству поломки, лучшей архитектуре и меньшему техническому долгу.

Вы даже можете ввести NuGet в уравнение, используя либо размещенный на внутреннем сервере, чтобы опубликовать свой общий компонент, и уведомить каждого из потребителей, когда доступна новая версия.