Возможные решения для использования TFS и SVN в проектах нескольких поставщиков? - PullRequest
Новая
       51

Возможные решения для использования TFS и SVN в проектах нескольких поставщиков?

2 голосов
/ 28 апреля 2011

Я работаю над созданием решения по управлению исходным кодом, которое позволит нескольким поставщикам вносить свой вклад в один проект (несколько сайтов Sitecore CMS в одной установке). В идеале мы хотели бы использовать TFS, поскольку она соответствует нашим внутренним требованиям и лучше всего поддерживается. Однако некоторые из наших поставщиков предпочитают SVN. Если мы решим использовать TFS, то, похоже, для этого есть ряд возможных решений.

1) Поставщики обязуются использовать TFS напрямую, с помощью инструментов MS и клиентских лицензий (например, Visual Studio для разработчиков и tfs.exe и т. Д. Для интерфейса).

2) Поставщики используют TFS, подключаются к своим текущим инструментам SVN (SVN Bridge / SVN Tortoise) и переходят к ним - по-прежнему требуется лицензия CAL на разработчика.

3) Поставщики используют одну лицензию CAL для создания базы кода из TFS, которую они затем используют в качестве хранилища SVN. Поставщики используют SVN локально, но используют постоянную интеграцию между хранилищем SVN и TFS для синхронизации.

Третий вариант выглядит дешевле с точки зрения лицензирования, но добавит значительную сложность и время для разработчиков при синхронизации и, вероятно, потеряет информацию о регистрации для каждого разработчика (один разработчик будет проверять все изменения, сделанные его командой TFS).

На самом деле нам не нужен высокий уровень детализации и сложности, просто базовая функциональность. Поставщики несут ответственность за свои команды, нам даже не нужно знать, кто что делал на этом уровне, просто что это было от продавца А или поставщика Б.

Каковы относительные недостатки и преимущества вышеуказанных подходов и какие инструменты облегчат мою жизнь?

1 Ответ

1 голос
/ 29 апреля 2011

Как вы указали, у вас есть несколько вариантов:

  1. Если ваши поставщики просто хотят использовать интеграцию, подобную проводнику Windows (подобно инструментам черепахи), они могут установить TFSЭлектроинструменты, которые включают в себя интеграцию с Explorer.Хотя этот вариант потребует от ваших поставщиков изучения новых инструментов (и, поначалу, это может немного расстроить), у него, безусловно, будет наименьшее количество «движущихся частей» и вероятность поломки.1008 * Вероятно, самый сложный маршрут.Хотя SVNbridge отлично справляется со многими задачами, он, вероятно, не обеспечит всех функций, которые потребуются вашим пользователям, например, ветвления и слияния.

  2. Своевременная миграция предлагает SVN дляИнструмент миграции TFS , который полезен для первоначальной миграции SVN в TFS, но (если я помню) имеет некоторые шаги ручного разрешения, которые усложнили бы его автоматизированное использование.Однако, возможно, стоит изучить, как это можно использовать для синхронизации.В этом случае, однако, вам следует проконсультироваться со своим контактным лицом Microsoft относительно лицензирования CAL: использование автоматического инструмента для синхронизации между TFS и другой системой не обязательно снимает ограничения CAL.

...