Слияние TFS для пользователей, которые используются для VSS

Question

Я просто перенесли команду из 7 разработчиков из VSS в TFS. Я перенесил весь их код в папку DEV, которую я затем разветвил в папку QA (которую я разветвил в папку PROD). Разработчики обычно не работают над одними и теми же файлами, но есть некоторые общие классы полезности. Весь код предназначен для большого веб-сайта ASP.NET. Когда разработчики готовы объединиться с DEV в QA, они хотят только объединить свои изменения. Например, предположим, что Developer1 работает над проектом в течение последних 3 месяцев, и он готов объединить весь свой код в QA. Однако Developer2 работает над другим проектом за последние 2 месяца, который не готов к объединению. Изменения Developer1 и Developer2 никоим образом не зависят друг от друга, но они не разделены на разные структуры папок, и каждый из них регулярно получает последнюю информацию. Кажется, что разработчик не может объединить свои изменения, не сводя вместе все изменения разработчика2. В настоящее время разработчик1 просматривает окно «Ожидающие изменения» и «Отмена ожидающих изменений» для всех изменений Developer2, но это занимает много времени. Они могут объединять каждый файл по отдельности, но это также требует много времени. Есть ли более простой способ? Я собираюсь иметь коронар, если узнаю, что еще один человек объяснит, насколько проще было работать в VSS.

Answer 1

Похоже, что лучшая стратегия (продолжение) - это разветвление по проекту. Если Dev1 и Dev2 работают над принципиально разными вещами, они должны иметь свою собственную ветвь кода.

Помните, что все в TFS хранится как дельта и указатели, поэтому вы не увеличиваете размер своего репозитория, не увеличивая его размер. Пока файл не изменится, новая ветвь является только указателем на исходный файл, а затем, когда файл проверен, сохраняется только дельта.

В вашей текущей ситуации вы делаете так называемое слияние «вишневого». Это не забавная вещь (как вы узнаете), и она подвержена ошибкам PEBKAC. По этой причине слияние вишневых щелей категорически не рекомендуется. Однако, если вам нужно делать слияния вишни, вы можете установить некоторый контроль путем слияния с помощью набора изменений (вместо последнего).

Для этого определите набор изменений, которые Dev1 проверил в вашей ветке Dev, затем объедините эти изменения в свою ветку mainline. Вам нужно будет сделать это в порядке от старейшего до новейшего, чтобы получить все файлы. Лучше всего, если вы собираетесь это сделать, придется либо написать утилиту для этого, либо перейти к командной строке TF.EXE, чтобы вы могли объединить свои слияния.

Не забудьте сделать ваши сливается в чистую рабочую область, и вы можете партия все ваши слияниям, прежде чем проверить в.

Основной урок, который вы изучаете здесь является то, что ваша стратегия разветвление/методология является одним из самые важные вещи о SCM (в общем). Мы перешли из StarTeam в TFS чуть более полутора лет назад, и когда мы это сделали, мы потратили примерно 4 месяца на пересмотр нашего подхода к ветвям, пока не придумали что-то, что соответствует нашей среде и нашим процессам разработки.

Answer 2

Есть ли причина, по которой они, кажется, ветвятся все вместо своих собственных изменений?

В диалоговом окне слияния задается вопрос, хотите ли вы разветвить «все изменения до определенной версии» или «только конкретные изменения». Если вы выберете последний, вы можете вишнево выбрать свои изменения и не нужно принимать код каждого. Предполагая, что каждый разработчик работает над неперекрывающимся набором файлов, это не то, что должно вызывать проблемы.