Проблемы простого слияния TFS

Кажется, что мой сценарий примерно такой же простой, как он может получить. У меня есть Main и ветвь Dev. Я выбрал директорию в Dev, которая имеет только мой код и выполнила слияние (на основе всех наборов изменений до определенного набора изменений.

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

Изменен набор настроек 322.

Удаление C: \ SourceEagleConnect \ Main \ BizTalk \ ACH \ Sample \ Sample1.sln TF14119: невозможно объединить удаление $ / EagleConnect / Dev / BizTalk / ACH / BizTalk в $ / EagleConnect / Main / BizTalk / ACH / BizTalk, потому что один из его дети были переименованы или перемещены. TF14121: Изменения, ранее внесенные в $ / EagleConnect / Dev / BizTalk / ACH / Sample1 / Sample1.sln, которые не были объединены, будут отброшены путем слияния удаления $ / EagleConnect / Dev / BizTalk / ACH / Sample1 / Sample1.sln , TF14119: Невозможно объединить удаление $ / EagleConnect / Dev / BizTalk / ACH / BizTalk в $ / EagleConnect / Main / BizTalk / ACH / BizTalk, потому что один из его детей был переименован или перемещен.

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

Затем я использовал инструмент сравнения для сравнения диска Dev и Main, и я вижу много файлов в Main, которые не имеют изменений от Dev.

В одном конкретном файле я сделал следующий анализ. Я сделал «просмотр истории» как в Dev, так и в Main, затем я побежал из командной строки «tf объединяет Dev / file Main / file».

Просмотр истории Dev показывает:

213 edit nwalters 8/6/2010 2:43 PM New Host Names based on application instead of adapter 159 edit nwalters 7/20/2010 10:16 AM BTDF - reset to use new SettingsFileGenerator.xml, improved to handle new EagleConnectConnectionString 50 branch nwalters 6/22/2010 10:04 AM Original checkin of "Dev" Branch 

Просмотр истории на главных выставках:

 323 merge, edit nwalters 9/23/2010 2:02 PM BizTalk-Only Merge 09/23/2010 (there were some ACH warnings) 175 merge, edit nwalters 7/27/2010 2:29 PM Check-in after big merge of all BizTalk from Dev to Main 49 add nwalters 6/22/2010 10:00 AM Original checkin of EagleConnect source cod to TFS 

«tf merges» показывает:

 Changeset Merged in Changeset Author Date --------- ------------------- -------------------------------- ---------- 159 175 nwalters 7/27/2010 213 323 nwalters 9/23/2010 

Поэтому он выглядит как changeet 213, изменение, которое «потеряно», было включено в слияние 323. Тем не менее, когда я смотрю на Основной исходный код, его нет (его нет на диске, и если я делаю «представление» [из истории в проводнике источника], он тоже не входит в TFS).

Когда я сейчас сливаюсь, он говорит «ничего не сливаться».

Solutions Collecting From Web of "Проблемы простого слияния TFS"

Что касается вашего первого вопроса, слияние TFS из ветви источника в ветку Target НЕ автоматически регистрирует изменения слияния в целевой ветке. Способ слияния TFS работает – если вы используете параметр «Последняя версия» для слияния:

  1. он сравнивает историю изменений в целевой ветке и определяет, какие изменения из источника необходимо объединить в целевую.

  2. он копирует SERVER версию наборов изменений в ветви Source в ЛОКАЛЬНУЮ версию ветви Target (это дает вам возможность создать локальную цель с этими изменениями и гарантировать, что она не сломает вашу существующую сборку, прежде чем вы ее проверите).

  3. после того, как вы удовлетворены изменениями слияния в ЛОКАЛЬНОМ филиале «Цель», вам необходимо вручную зарегистрировать эти изменения в ветке «Цель».

Следовательно, перед слиянием вам всегда нужно получить последнюю версию ветки «Цель» на вашем локальном компьютере.

Я получил последнюю версию на другой машине, и код идеально сочетался (сравнение дисков с Dev на Main). Итак, я работаю, очевидно, что каждый элемент, который не соответствует, вызван одним из следующих:

  1. Он был изменен за пределами TFS
  2. Он никогда не проверялся в TFS (некоторые из них я забыл проверить, другие были файлы типа bin / debug, которые не будут проверяться).