Удаление главной магистрали в иерархии ветвей и наличие ветвей одного уровня

Question

Я решил разделить свое решение TFS на 4 ветви.Первоначально у меня было одно решение VS, которое находилось под контролем исходного кода, под названием «Разработка».По мере роста продукта я решил создать 3 филиала для трех клиентов, которые его используют.Итак, у меня есть:

1. Разработка
2. Разработка-Клиент1
3. Разработка-Клиент2
4. Разработка-Клиент3

У меня был новый запрос на изменение для «Development-Client2», я написал код и внес изменения.Когда я проверил исходные файлы, я заметил, что «Разработка» также учитывает эти новые изменения.

Я ожидал, что когда я разветвлю «Разработка», у меня будет 4 версииРешение и я мог бы объединить наборы изменений между ними.

Из моей текущей настройки, кажется, что любые изменения, которые я делаю в # 2, # 3 или # 4, будут автоматически добавлены в # 1.

Так как ветвление произошло недавно, я чувствую, что могу разобраться с ним сейчас.Кто-нибудь знает, что мне нужно, чтобы получить 4 независимых филиала?

ОБНОВЛЕНИЕ

В моем файле решения у меня есть 6 проектов:

1. Веб-сайт ASP.NET (работает на локальном хосте).
2. Консольное приложение
3. Библиотека классов (бизнес-логика)
4. Библиотека классов (доступ к данным)
5. Библиотека классов (сущности)
6. Библиотека классов (общие методы)

Я заметил, что для моих новых функций в 'Development-Client2' изменения в проектах 2-6 ​​не были добавлены в ветку 'Development' или 'Development-Client1' или 'Development-Client3'branch.

Однако любые изменения, внесенные мной в' ASP.NET Web Site (работающий на localhost) 'в' Development-Client2 ', были реплицированы во все ветви.

ОБНОВЛЕНИЕ 2

Я думаю, что произошло в следующем порядке:

1. У меня было решение под названием Разработка под управлением исходного кода (TFS)
2. Я создал ветку под названием Development-NewFeatureX
3. Я разветвлял Development-NewFeatureX 3 раза, у меня остались Development, Development-NewFeatureX, Development-Client1, Development-Client2, Development-Client3
4. Я удалил ветвь Development-NewFeatureX.
5. Я сделал загрузкиизменений в проектах 1, 3, 4 и 5 в ветке Development-Client2.
6. На этом этапе я понял, что изменения проекта 1 были реплицированы в другие ветви.

Я также заметил, что в компоненте Source Explorer в TFS файл решения каждой из ветвей указывает на «Development-NewFeatureX» для проекта [ASP.NET Web Site (выполняетсяпротив localhost)].

Я попытался проверить файл решения и изменить путь:

.. Development-NewFeatureX / ASPNETSITE

to:

.. Development-ClientX / ASPNETSITE

Однако это просто не работает, и контроль исходного кода перезаписывает файл решения.

Я думаю, что именно в этот момент я признаю поражение и пытаюсь найти новое решение.

Если кто-нибудь из TFS-гуру знает, о чем я говорю, дайте мне совет

РЕЗЮМЕ ПРОБЛЕМЫ

• У меня 4 ветви.
• Каждый раз, когда я открываю файл решения любой из веток проекта: «Веб-сайт ASP.NET (работает на локальном хосте)» он ничем не отличается.то есть это тот же самый.Поэтому, если я внесу изменения в этот проект в какой-либо ветке, это произойдет во всех из них.
• Сопоставленная папка этого проблемного проекта - это ветвь, которую я ранее удалил.кажется правильным с ветками / проектами.Только когда я открываю файл решения, сайт ASP.NET всегда один и тот же.
• Пожалуйста, смотрите скриншот.

Answer 1

По моему опыту, VS всегда требовал владения веб-сайтами от localhost.

Вот что всегда работало для меня:

• Создание веб-проектов только так: Файл -> Новый проект -> Интернет
• Всегда указывать местоположение проекта, т. е. w: \ project \ code \ AppWebLocation
• Затем вы можете в Свойствах проекта -> Интернет -> Серверы
  • использовать localhost / virtualDir - он сделает сопоставление для вас
  • использовать VS Development Server - я ненавижу это: - \
  • использовать IIS Express - я думаю, что localhost - лучший вариант.

Я думаю, что случилось в вашем случае: вы использовали Файл -> Новый проект веб-сайта, он поместил проект в файл решения, а затем подключил этот веб-сайт к своемуКлиентское решение, как было в том же месте.С тех пор TFS собирал свои файлы из одного места для всех клиентов.который пита.

Answer 2

Вот как я бы изложил свою стратегию ветвления и развития, используя вашу ситуацию:

• Root
  • Разработка (Папка)
    • Main (Где живет общий базовый код)
    • Заказчик А (основной филиал)
    • Заказчик B (основной филиал)
    • Заказчик X (основной филиал)
  • Release
    • Customer A (папка для стабильного разработчика Customer A)
      • 20110101 (ответвление по дате выпуска или другое обозначение, например, версия)
      • 20110301 (здесь исправлены производственные ошибки, связанные с Заказчиком A)
    • Клиент B
      • 20120210
    • Клиент X
      • 20120101

На вашем локальном компьютере в IIS настройте веб-сайт с различным портом для каждого клиента и главным филиалом на порту 80. Таким образом, вы можете получить доступ ко всем сборкам parralel без переключения.

Эта стратегия позволит вам делать общие исправления ошибок или общие функции в Main и делать FI в ветках Customer, когда это необходимо. При необходимости вы можете сделать RI в Main от клиента, но вам действительно не нужно, если вы придерживаетесь цели филиалов.

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

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

Answer 3

Несколько вещей, которые нужно попробовать.

С тех пор, как у вас появился 2010 год: пробовали ли вы отслеживать один из ваших наборов изменений в визуализаторе филиала?Выберите конкретный набор изменений, сделанный в одной из веток вашего внука, который, по вашему мнению, реплицировался обратно в другие ветви, и посмотрите, где TFS думает, что он пошел?Если он горит в других ветвях с новыми номерами наборов изменений, то это свидетельствует о том, что произошло слияние.Затем вы можете найти набор изменений слияния и посмотреть, как это произошло.

Если слияний нет, то как насчет истории конкретных файлов в других ваших ветках, которые, по вашему мнению, были реплицированы из других источников, и проверить ихразличия, чтобы увидеть, откуда пришли их изменения?

Проверяли ли вы настройки IIS / виртуальных каталогов?Каждая ветка указывает на правильный виртуальный каталог?

Сколько локальных рабочих областей вы настроили и как они настроены?Несколько рабочих пространств в TFS могут привести к путанице, потому что то, что вы просматриваете в Source Control Explorer, может не совпадать с тем, которое вы видите в окне Pending Changes, и это может привести к тому, что проверки будут проходить не в том месте, где вы собираетесь.

Наконец, мне любопытно - с какой стати вы хотите, чтобы ветви отделялись от своих прародителей и друг от друга?Мне не ясно, в чем заключается преимущество / мотив для удаления этой родительской ветви и обрезания их всех;TFS не любит, чтобы эти родительские / дочерние отношения были сохранены?Или это достаточно умно, чтобы помнить?