Team Foundation Server - ранее объединенные наборы изменений снова появляются в мастере слияния - PullRequest
Новая
       7

Team Foundation Server - ранее объединенные наборы изменений снова появляются в мастере слияния

8 голосов
/ 02 февраля 2012

Наша структура СКМ следующая: 

Main
 |--Release

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

Чтобы выполнить слияние, я бы с помощью Source Control Explorer щелкнул правой кнопкой мыши на «Main»> «Ветвление и слияние»> «Merge». Выберите «Выбранные наборы изменений». Существует только одна целевая ветвь (выпуск). Выберите наборы изменений, протестируйте локально, зарегистрируйтесь, чтобы выпустить. Это работало отлично в течение нескольких месяцев.

Однако сегодня некоторые очень ранние наборы изменений только что «появились» в мастере управления слияниями источников в верхней части списка. Но странно, не все из них.

Эквивалентная команда CLI: 

tf merge /candidate /recursive [source] [destination]

Эта команда возвращает следующий список: 

   3* Person.One      27/11/2009
  43* Person.Two      21/12/2009
  50* Person.Two      22/12/2009
  54* Person.Two      22/12/2009
  57* Person.Two      22/12/2009
 114* Person.One      12/01/2010
 116* Person.One      13/01/2010
 128* Person.One      15/01/2010
 138* Person.One      19/01/2010
 139* Person.One      19/01/2010
7846  Person.Three    19/01/2012
7847  Person.Three    19/01/2012
7848  Person.Three    19/01/2012
7849  Person.Three    19/01/2012
8030  Person.Four     31/01/2012
8031  Person.Four     31/01/2012
8032  Person.Four     31/01/2012
8045  Person.Five     01/02/2012
8050  Person.Four     01/02/2012
8052  Person.Six      01/02/2012
8053  Person.Six      01/02/2012
8054  Person.Three    01/02/2012
8055  Person.One      01/02/2012
8056  Person.Seven    01/02/2012
8057  Person.Five     01/02/2012
8058  Person.Six      01/02/2012
8059  Person.Five     01/02/2012
8060  Person.Five     01/02/2012
8063  Person.Five     02/02/2012
8068  Person.Five     02/02/2012
8069  Person.Eight    02/02/2012
8070  Person.Five     02/02/2012
8071  Person.Five     02/02/2012
8072  Person.Five     02/02/2012
8073  Person.Three    02/02/2012
8074  Person.Three    02/02/2012
8077  Person.Seven    02/02/2012

Единственная «подсказка» - это звездочка, которая, как я считаю, означает, что частичное слияние уже завершено.

Я полностью ошеломлен тем, как это могло произойти. На сервере не было администрирования. Это произошло за последние 6 часов или около того.

Если я попытаюсь выполнить слияние в своем рабочем пространстве, у меня не будет конфликтов, и, ну, я не совсем уверен, что произойдет, если я зарегистрируюсь. Очевидно, что файлы и структура сильно изменились за два года!

Я могу использовать команду tf merge / discard, чтобы «заставить их уйти», но я бы хотел докопаться до , почему это произошло, для моего собственного любопытства, если ничего больше.

ТИА

Обновление:

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

tf merge /discard /recursive [source] [destination] /version:C3~C139

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

К сожалению, если я бегу 

tf merge /candidate /recursive [source] [destination]

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

   3* Person.One        27/11/2009
  43* Person.Two        21/12/2009
  50* Person.Two        22/12/2009
  54* Person.Two        22/12/2009
  57* Person.Two        22/12/2009
 114* Person.One        12/01/2010
 116* Person.One        13/01/2010
 128* Person.One        15/01/2010
 138* Person.One        19/01/2010
 139* Person.One        19/01/2010
 140  Person.One        19/01/2010
 141* Person.One        19/01/2010
 142* Person.Two        19/01/2010
 149* Person.Two        20/01/2010
 152* Person.Two        20/01/2010
 160* Person.Two        21/01/2010
 161* Person.Two        21/01/2010
 165* Person.One        21/01/2010
 167* Person.Two        22/01/2010
 173* Person.Two        22/01/2010
 199* Person.Two        27/01/2010
 200* Person.One        27/01/2010
 203* Person.Two        28/01/2010
 204* Person.Two        28/01/2010
 205* Person.Two        28/01/2010
 206* Person.Two        28/01/2010
 208* Person.Two        28/01/2010
 213  Person.Two        28/01/2010
 215* Person.Two        28/01/2010
 235* Person.Two        01/02/2010
 238* Person.Two        02/02/2010
 241* Person.Two        02/02/2010
 259* Person.Two        04/02/2010
 262* Person.Two        04/02/2010
 264  Person.Two        05/02/2010
 296* Person.Two        10/02/2010
 309* Person.Two        11/02/2010
 316* Person.Two        12/02/2010
 317* Person.Two        12/02/2010
 320* Person.Two        12/02/2010
 338* Person.Two        15/02/2010
 353* Person.Two        16/02/2010
 365* Person.Two        18/02/2010
 394* Person.Two        22/02/2010
 399* Person.One        22/02/2010
 400* Person.One        22/02/2010
 401* Person.Two        23/02/2010
 403* Person.Two        23/02/2010
 404* Person.Two        23/02/2010
 405* Person.Two        23/02/2010
 424* Person.One        25/02/2010
 426* Person.Two        26/02/2010
 444* Person.Two        02/03/2010
 445* Person.One        03/03/2010
 461* Person.Two        08/03/2010
 476* Person.One        10/03/2010
 477* Person.One        10/03/2010
 478* Person.One        10/03/2010
 501  Person.One        12/03/2010
 502  Person.One        12/03/2010
 503  Person.One        12/03/2010
 504  Person.One        12/03/2010
 506  Person.One        12/03/2010
 511* Person.One        12/03/2010
 515* Person.One        15/03/2010
 517* Person.Two        15/03/2010
 518* Person.One        15/03/2010
 522  Person.One        16/03/2010
 523  Person.One        16/03/2010
 538  Person.Two        17/03/2010
 539  Person.Two        17/03/2010
 540  Person.Two        17/03/2010
 543  Person.One        17/03/2010
 581* Person.Two        18/03/2010
 582* Person.Two        18/03/2010
 644* Person.Two        26/03/2010
 706* Person.One        30/03/2010
 918* Person.One        13/05/2010
1594* Person.One        15/07/2010
1601* Person.One        16/07/2010
1626* Person.Three      20/07/2010
1627* Person.Three      20/07/2010
6153* Person.One        17/08/2011
7691* Person.Four       11/01/2012
7846  Person.Four       19/01/2012
7847  Person.Four       19/01/2012
7848  Person.Four       19/01/2012
7849  Person.Four       19/01/2012
8030  Person.Five       31/01/2012
8031  Person.Five       31/01/2012
8032  Person.Five       31/01/2012
8050  Person.Five       01/02/2012
8054  Person.Four       01/02/2012
8073  Person.Four       02/02/2012
8074  Person.Four       02/02/2012
8104  Person.Six        03/02/2012
8110  Person.Six        03/02/2012
8112  Person.Seven      03/02/2012
8113* Person.Five       03/02/2012
8114* Person.Five       03/02/2012
8127  Person.Seven      06/02/2012
8128  Person.Seven      06/02/2012
8130  Person.Eight      06/02/2012
8135  Person.One        06/02/2012
8138* Person.Five       06/02/2012
8140  Person.Five       06/02/2012
8142  Person.Five       06/02/2012
8143  Person.Nine       06/02/2012
8144  Person.Nine       06/02/2012
8145  Person.Ten        06/02/2012
8146  Person.Eleven     06/02/2012

Я действительно понятия не имею, что послужило причиной этого. Любой совет приветствуется.

Ответы [ 3 ]

5 голосов
/ 02 февраля 2012

Вы правы, «*» означает, что некоторые файлы в changset 3 были объединены в «release», а другие - нет.Обычно это происходит путем отмены проверки файлов в окне ожидающих изменений при слиянии.

Вы недавно обновились с TFS 2008?У нас была такая же ситуация после нашего обновления.В TFS 2008, если вы сняли отметку с файла регистрации слияния, TFS предполагала, что вы никогда не захотите слить этот файл когда-либо!Единственный способ выбрать непроверенные файлы - это перейти в командную строку и использовать tf merge /force

. В TFS 2010 поведение изменилось, и теперь, если вы выполните частичное слияние, TFS всегда будет напоминать вам, что естьвыдающиеся кандидаты на слияние в частично объединенной ревизии.

Вы можете сделать 2 вещи.

  1. Объедините наборы чередований (маловероятно, что вы хотите сделать это, учитывая прошедший промежуток времени)
  2. используйте команду tf merge /recursive /discard /version:C3~C139 [source] [destination] Это скажет TFS, что вы этого хотитедумать, что это сделало слияние, даже если оно не
4 голосов
/ 02 мая 2012

Мы определили, что причиной такого поведения было то, что ранее удаленный файл был «воскрешен» в основной ветви, в том смысле, что был создан новый файл с тем же именем.

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

Казалось, полное слияние решило проблему.

0 голосов
/ 03 марта 2016

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

Я решил объединить некоторые изменения из старой версии (под названием «2.30») в новую версию (под названием «2.31») через основную версию, и когда я начал объединять изменения из основной версии в версию 2.31, я увидел несколько Наборы изменений в мастере слияний много лет назад - один из них был с 2011 года!

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

Итак, я объединил все изменения, которые были внесены в ветку выпуска 2.31, обратно в основную и проверил все это. Прежде чем создавать новую ветку для замены 2.31, я подумал, что снова попробую мастер слияния (слияние с основной 2.31), чтобы увидеть, что это волшебным образом прояснило это, и это сделало. Ни одна из этих старых ревизий не появилась снова.

Очень странно.

...