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

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

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

• Создавайте веб-проекты только так: Файл -> Новый проект -> Веб.
• Всегда указывайте расположение проекта, т.е. w:\project\code\AppWebLocation
• Then you can in Project Properties -> Web -> Servers
  • use localhost/virtualDir - it will do the mapping for you
  • используйте VS Development Server - я ненавижу это :-\
  • используйте IIS Express - я думаю, что локальный хост - лучший вариант.

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

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

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

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

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

Сколько локальных рабочих пространств у вас настроено и как они настроены? Несколько рабочих областей в TFS могут вызвать путаницу, поскольку та, которую вы просматриваете в обозревателе управления версиями, может не совпадать с той, которую вы видите в окне «Ожидающие изменения», и это может привести к тому, что проверки будут проходить не там, где вы намеревались.

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

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

• Root
  • Development (Folder)
    • Main (Where the common base code lives)
    • Заказчик А (филиал основной)
    • Заказчик Б (филиал основной)
    • Заказчик X (филиал основной)
  • Release
    • Customer A (folder for stable dev Customer A)
      • 20110101 (branch by release date, or some other designation like version)
      • 20110301 (здесь исправлены производственные ошибки, связанные с клиентом А)
    • Customer B
      • 20120210
    • Customer X
      • 20120101

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

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

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

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