Связывание папки управления исходным кодом TFS из другого проекта TFS - PullRequest
2 голосов
/ 21 февраля 2011

Мы переходим на TFS 2010 (из PVCS) для контроля версий и отслеживания рабочих элементов

Насколько я понимаю, вы должны иметь под контролем исходного кода для каждого проекта TFS все, что нужно для построения проектных решений и т. Д.

Это нормально для новых решений / проектов .NET, но у нас есть большая коллекция устаревших Delphi 6 проектов с общими исходными библиотеками, которые мы хотим перенести в TFS для контроля исходного кода и строить. Моя проблема в том, как мы управляем несколькими проектами TFS, которые хотят сохранить между собой определенный набор исходных файлов.

Исторически с PVCS у нас были проекты для каждого решения (например, A & B) и отдельный проект для общего исходного кода (например, C). Пользователи получат C, затем получат либо A, либо B (при необходимости отметив это) на диске, это будет выглядеть примерно так:

$\Projects\C
$\Projects\B

Но B & C - это отдельные архивы PVCS.

Теперь вернемся к жизни с TFS 2010 в качестве нашего решения ALM ...

Если мы создадим проект TFS (1), который содержит исходный репозиторий для общего кода (C), то проектники, очевидно, смогут получить к нему доступ (допустим, проект TFS также содержит решение A), и все будет хорошо.

Теперь мы создаем новый проект TFS (2), в котором необходимо создать решение B. Решение Beacuse B сильно отличается от решения A. У нас не было никакой причины делиться управлением исходным кодом TFS проекта 1, поэтому мы создали новый репозиторий исходного кода, а не ветвление из 1. Теперь позже мы обнаружим необходимость в решении B для доступа к некоторым распространенным файлам из C (в 1). Упс!

Вопрос заключается в следующем; Могу ли я выполнить какой-либо wizzardry управления исходным кодом, который позволяет мне добавить в элемент управления soruce 2 папку, которая является символической ссылкой (для кражи термина файловой системы), в 1 source control для общего кода C?

Редактировать
Я должен отметить, что это весь устаревший код, а разделяемая исходная библиотека (C) - это просто тот разделяемый источник, который не встроен в библиотеку или другой двоичный файл, который мы могли бы просто добавить в A или B.

1 Ответ

5 голосов
/ 21 февраля 2011

В TFS 2010, как вы, возможно, знаете, они представили концепцию коллекции проектов (ПК) . Каждая коллекция проектов представляет собой совокупность командных проектов (TP) . Каждый ПК хранится в отдельной базе данных, а VCS хранится в базе данных.

Это означает, что на ПК есть один репозиторий VCS, а не TP. Каждый TP (по умолчанию) является корневой папкой в ​​каждой VCS (т. Е. TP1 будет в $ / Prj1, TP2 может быть в 4 / Prj2 и т. Д.)

Еще одно замечание: вы не хотите иметь одно решение на ТП. Думайте о ТП как о наборе продуктов, а о решении - как о его части.

Символические ссылки, согласно Visual Source Safe, больше не существуют в TFS, и я не уверен, что они вам нужны. Не рекомендуется создавать зависимость между одним решением и исходным кодом 1014 * другого решения.

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

Что произойдет, если Sln_A зависит от Common_Sln, вы создадите Common_Sln и принесете его двоичные файлы из места отбрасывания как часть вашего Get . Затем добавьте двоичные файлы в качестве ссылок.

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

Помогает ли это решить вашу проблему? Вот как я делаю это с проектами, с которыми я консультируюсь.

НТН, Ассаф.

...