Несколько Team Foundation Server - PullRequest
Новая
       19

Несколько Team Foundation Server

3 голосов
/ 12 декабря 2008

В настоящее время в нашей компании есть локальный TF-сервер, и мы собираемся сделать подмножество наших проектов с открытым исходным кодом (через Codeplex), но у нас возникают проблемы при смешивании двух серверов Team Foundation Server в одном решении. Похоже, Visual Studio не может быть подключен ко многим TF-серверам одновременно. Какой лучший способ справиться с этим?

  • Решение 1 : привязать проекты с открытым исходным кодом только к Codeplex, а проприетарные проекты - только к локальным. Связывайте и отменяйте привязку проектов в зависимости от того, где вы подключены -> Похоже, что VS не нравится идея. Проекты теряют привязки и начинают вести себя странно.

  • Решение 2 Свяжите все с локальным и используйте другое решение для подмножества с открытым исходным кодом -> Диспетчер рабочего пространства Team Explorer не использует перекрывающиеся деревья локальных папок даже на разных серверах, поэтому не вариант.

  • Решение 3 Свяжите все с локальным, используя TFS. Используйте другой элемент управления исходным кодом, например SVN, для подмножества с открытым исходным кодом. Похоже, это станет легко грязно, но у нас нет много вариантов.

Кто-то с открытыми исходными текстами столкнулся с такой проблемой ??

1 Ответ

2 голосов
/ 13 декабря 2008

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

Безопаснее иметь один единственный авторизованный репозиторий и просто создавать моментальные снимки для выпусков вех в другом.

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

...