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

Question

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

1. развитие
2. Разработка-Client1
3. Разработка-Client2
4. Разработка-Client3

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

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

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

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

ОБНОВИТЬ

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

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

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

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

ОБНОВЛЕНИЕ 2

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

1. У меня было решение под названием Разработка под управлением исходного кода (TFS)
2. Я создал ветку под названием Development-NewFeatureX
3. Я разветвлял Development-NewFeatureX 3 раза, у меня остались Разработка, Разработка-NewFeatureX, Разработка-Клиент1, Разработка-Клиент2, Разработка-Клиент3
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

чтобы:

..Development-ClientX / ASPNETSITE

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

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

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

РЕЗЮМЕ ЗАДАЧИ

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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