Можно ли переместить папки из одного набора веток TFS в другой и сохранить отложенные изменения?

В настоящее время наш проект TFS (TFVC, не git) содержит папку, в которой находится весь наш продукт. Эта папка содержит три ветви (Dev, Main и Release), каждая из которых, в свою очередь, содержит множество различных подпроектов. Мы пытаемся реструктурировать так, чтобы отдельные компоненты содержались в их собственной разветвленной структуре.

Вопрос. Можно ли переместить папку, содержащуюся в ветке (не в самой ветке), вместе с соответствующей папкой в ​​других ветках в новый проект TFS, сохраняя при этом связь и статус любые неслитые наборы изменений?

Вот схема желаемого конечного результата:

целевая структура

Мы хотим переместить каждую из папок «Проекта 1» (слева) в их собственную структуру ветвления (справа), но нам нужно, чтобы все неслитые наборы изменений «появились». То есть, если мы попытаемся выполнить слияние Dev с Main в новой структуре, нам будет представлен список (соответствующих) наборов изменений, которые не были объединены в старой структуре.

Это возможно? Если да, то какая серия команд tf/tfvc нам понадобится для этого? Я углубился в google, но не смог — либо потому, что я не знаю, как описать это удобным для поиска способом, либо это просто невозможно.

Что я пробовал:

  • Прямое перемещение/переименование каждой из папок в новый проект (предварительное создание каждой целевой ветки Dev/Main/Release)

    • The unmerged changesets were lost.
    • Все, что я получаю, это один набор изменений «переместить/переименовать», который появляется в неслитном списке для новых ветвей. Слияние этого приводит к тому, что все в целевой ветке перезаписывается (т. е. файлы ветки релиза теперь такие же, как и в dev).
    • На стороне + ожидающие полки «автоматически следуют», когда не полки

  • Разветвите каждую папку в новую структуру (на этот раз без предварительного создания целевых папок ветки)

    • This created three branches that weren't related to each other.
    • Я смог решить эту проблему, выполнив безосновательное слияние между ними (tf merge /baseless /recursive) и взяв файлы целевых веток в случае конфликта; с последующим перевоспитанием ветвей. (Как описано здесь)
    • В отличие от вышеописанного, сами файлы оказались правильными (ничего не перезаписывалось).
    • Необъединенные наборы изменений были потеряны.
    • Полки перемещаются в исходное место.

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

Изменить: в ответ на ответ, который был опубликован, а затем удален:

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


tfs tfvc
person pinkfloydx33    schedule 14.12.2018    source источник
comment
Скорее всего, это проблема Git, а не проблема TFS. Если вы сможете понять, как получить желаемое с помощью операции Git, проблема с TFS должна решиться сама собой.   -  person Robert Harvey    schedule 14.12.2018
comment
Мы не используем Git. Мы используем TFS+TFVC, отсюда и теги. К вашему сведению, это становится проблемой TFVC и поиском правильной операции/tf команд TFVC, что мы и ищем.   -  person pinkfloydx33    schedule 14.12.2018
comment
Теги хороши для категоризации вопросов, но я редко смотрю на них при чтении постов. Вы можете упомянуть об этом в теле вашего вопроса. Что бы это ни стоило, я не знаю кого-либо еще, кто использует TFVC; вся экосистема объединилась вокруг Git.   -  person Robert Harvey    schedule 14.12.2018
comment
Я хотел бы, чтобы мы были на Git, но, к сожалению, я не думаю, что это произойдет в ближайшем будущем. Я забыл, что Git + TFS был вещью, поэтому я предположил, что это очевидно из поста, хотя добавит в тело   -  person pinkfloydx33    schedule 14.12.2018
comment
@pinkfloydx33 Для справки: (stackoverflow.com/questions/28990323/)   -  person Kousic    schedule 19.12.2018
comment
@Kousic, спасибо, я это видел, и это не совсем то, что мне нужно. rename/move, кажется, не помогает здесь при попытке перейти в новую ветку, особенно в три сразу. Затем он создает операцию, которая сама хочет быть объединена   -  person pinkfloydx33    schedule 19.12.2018
comment
(fillanypdf.com/Download /Общий/)   -  person Kousic    schedule 19.12.2018
comment
Может быть, немного опоздал на игру. Но если потеря истории — это нормально, почему нельзя просто скопировать папки? Часть ожидающих изменений может быть решена путем получения последней версии в другую папку, перемещения материала, регистрации. Затем скопируйте все из исходной папки, все файлы, которые отличаются, будут ожидающими изменения в новой папке. Я пропустил что-то очевидное с этим подходом? ????   -  person Mötz    schedule 22.12.2018
comment
@Mötz создает новый набор изменений, содержащий все файлы, которые затем помещаются в список ожидающих слияния после фиксации. Но в остальном ваша стратегия не работает: нам нужно знать, что это за ожидающие изменения. Это не просто один файл, который может отличаться, и нам нужна возможность выборочного объединения. Есть ожидающие изменения, которые должны перейти от Dev к основному, а другие — от основного к выпуску и загрузке. Я еще не придумал стратегию. может быть есть способ превратить его в 5 ветвей (2 несвязанных) и медленно сложить их с помощью серии необоснованных слияний, но непроверенных и сложных   -  person pinkfloydx33    schedule 23.12.2018
comment
Я упустил из виду необъединенные наборы изменений между ветвями, извините за это. Как насчет расширения/разветвления всех ваших веток 3 раза, по 1 для каждого проекта. Это оставило бы вас с набором Dev, Main и Release для каждого проекта. Теперь вы можете удалить ненужные папки проекта для каждого набора, так что у вас останутся Dev[Project-1], Main[Project-1], Release[Project-1], Dev[Project-2], Main[Project-2]. , Релиз[Проект-2], Разработка[Проект-3], Основной[Проект-3], Релиз[Проект-3]   -  person Mötz    schedule 23.12.2018
comment
Не бери в голову. Я начинаю понимать, в чем проблема. Если бы моя идея увенчалась успехом, нам пришлось бы перейти от первого набора изменений, воспроизвести все наборы изменений из исходной ветки (сохранить исходное имя в качестве комментария для проверки), чтобы это сработало.   -  person Mötz    schedule 23.12.2018
comment
У меня была похожая мысль. Разветвляйте каждую папку, выполняйте всю новую работу в New-Dev. Когда все готово, слияние меняется с old-Dev на old-main и new-main (безосновное). После завершения удаления старого Dev, безосновательного слияния и повторного родителя. Повторите промывку для основного-›выпуска. Проблема в том, что это все равно будет куча необоснованного слияния между ними (и будет работать только в том случае, если ничего не нужно сливать из new-Dev в new-main), и, скорее всего, его будет трудно отследить. Я думаю, что это могло бы сработать, хотя я не уверен, что у меня есть конкретика, и я хотел бы избежать чего-то настолько сложного, если это вообще возможно.   -  person pinkfloydx33    schedule 23.12.2018
comment
Также следует отметить, что движущей силой всего этого является то, что мы хотим создать четвертую альфа-ветвь, по крайней мере, для одного из проектов, который будет действовать как квазифункциональная ветвь. К сожалению, у нас нет ветки (мы не можем сказать о текущем положении вещей). Это будет серьезным толчком в правильном направлении.   -  person pinkfloydx33    schedule 23.12.2018

Ответы (1)


arrow_upward
1
arrow_downward

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

  1. Разветвите папку старый Release > Project[x] в ветку new Project[x] > Release.
  2. Разветвите новый Project[x] > Release Branch в new Project[x] > Main.
  3. Объедините (безосновательно) папку old Main > Project[x] (указав набор изменений, из которого был ответвлен старый выпуск) в новый проект. [x] > Основная ветвь
  4. Разветвите новый проект[x] > основную ветвь в новый проект[x] > ветку разработки.
  5. Объедините (безосновательно) папку old Dev > Project[x] (указав набор изменений, из которого был ответвлен старый Main) в новый Project[ x] > ветка разработки
  6. Повторите для других проектов

Цель состоит в том, чтобы создать новые отношения слияния ветвей (путем ветвления [новой] Release к [New] Main, а затем [New] Main к [New] Dev. На этом этапе отношения слияния установлены, и все ветви находятся в одном и том же месте. Затем мы безосновательно объединяем [старое] с [новым] для основного и Dev. Для Main мы хотим расставить точки безосновательного слияния в состоянии, где Main и Release совпадают (в старом). Для Dev мы хотим сделать безосновательное слияние в состоянии, где Dev и Main одинаковы (в старом). Затем могут произойти дополнительные слияния из [старого] в [новый], и они должны быть обнаружены как слияемые изменения из [нового] ​​в [новый]. ] аналогично тому, как они находятся в [старом] на [старый]

Вы потеряете наборы полок (но всегда сможете снять их с полки в старом месте, зарегистрироваться и объединиться с новым), но история должна сохраняться до тех пор, пока старый проект не будет уничтожен.

person Jansen McEntee    schedule 27.12.2018
comment
Это выглядит хорошо, и я собираюсь попробовать. К сожалению (если это сработает), вы пропустили награду в 350 баллов, которую я получил за вопрос, срок действия которого истек на днях. Наши филиалы были разветвленными, начиная с основного. Main разветвлялся на Dev, а затем Main разветвлялся на Release (текущее отношение таково, что Main является родителем обоих, но при слиянии мы объединяем Dev->Main->Release). Имея это в виду, можете ли вы обновить ответ, предполагая, что это будет иметь значение? - person pinkfloydx33; 27.12.2018
comment
Да, конечно, могу, но я хотел бы задать следующий вопрос: где у вас есть ожидающие изменения слияния? Я предполагал, что Main › Release и Dev › Main. Но есть ли у вас также ожидающие изменения Main › Dev? - person Jansen McEntee; 27.12.2018
comment
Не только dev-›main и main-›release - person pinkfloydx33; 27.12.2018
comment
хорошо, я обновил ответ, но, если подумать, первоначальный способ должен работать (может быть, даже лучше), поскольку релиз в этом случае самый стабильный. Но дайте мне знать, как это работает, и я могу внести соответствующие обновления. - person Jansen McEntee; 27.12.2018
comment
Спасибо. Слишком поздно (для меня) начинать что-либо пробовать, но я попробую завтра утром. я буду держать вас в курсе - person pinkfloydx33; 27.12.2018
comment
Это не работает, но я думаю, что понимаю, как это должно работать. Во-первых, когда у меня возникают конфликты на безосновательной основе, я предполагаю, что мне следует взять исходную версию (не целевую)? 2. Похоже, что мне тогда нужно объединить ВСЕ наборы изменений (с самого начала) для каждой старой-›новой ветки, чтобы привести их в желаемое состояние (поскольку изменения еще не находятся в [Новом ])? 3. Безосновательное слияние оставляет новый неслитый набор изменений в [Новый]; Я должен быть в состоянии удалить это с помощью /discard, верно? 4. Если есть какой-либо необъединенный Old Main-›Old Release, он не отображается ни в одном из ожидающих списков (кроме, конечно, old main-›old Release) [продолжение] - person pinkfloydx33; 28.12.2018
comment
5. Поскольку я не слишком интересуюсь историей, могу ли я выбрать произвольный более поздний набор изменений в качестве безосновательного источника? (например, когда мы в последний раз объединились в Release)? Похоже, это даст мне меньший список для ручного обслуживания. 6. Должна ли моя исходная ветка использовать последний исходный код или мне следует указать набор изменений? 7. Поскольку похоже, что мне придется вручную объединять каждый набор, могу ли я просто создать ОДНУ ветку на основе оригиналов (например, Dev), безосновательное слияние, ЧТО с использованием более позднего набора изменений, и просто повторно разветвить оттуда (для нового основного/ релиз) и вручную объединить невыполненные наборы изменений (находящиеся в DEV)? - person pinkfloydx33; 28.12.2018
comment
2. да это тоже правильно. Я могу прояснить это в своем ответе, но также и то, почему я упомянул, что может быть проще начать с Release, а не с Main (поскольку все изменения произошли в Main и Dev). По сути, вы хотите иметь отношения слияния между [New]Dev › Main › Release, где все они находятся в одном и том же состоянии (код одинаков). Когда вы выполняете безосновное слияние от старого к новому, вы устанавливаете отношения слияния между старым и новым, но вы хотите выбрать набор изменений, в котором две связанные ветви были в одном и том же состоянии. Затем, когда вы объединяете дополнительные изменения из старого [продолжение] - person Jansen McEntee; 28.12.2018
comment
Я откатил свой ответ, чтобы отразить использование ветки выпуска в качестве начала 4. Когда вы выполняете безосновательное слияние [старого] основного с [новым], вы нацеливаете набор изменений, в котором основной находится в том же состояние как Релиз. Таким образом, когда вы объединяете любой другой набор изменений, помимо этого, из [старого] основного в [новый] основной, он будет распознан как объединяемое обновление для выпуска. 5. вы можете или вы можете объединить сразу несколько наборов изменений из [старого] в [новый], но имейте в виду, что это создаст новый набор изменений в [новой] ветке, и если при объединении с [ новый] до [новый] - person Jansen McEntee; 28.12.2018
comment
7. Этот процесс лучше всего работает, начиная с наиболее стабильной ветки (или с наименьшим количеством относительных изменений), а затем двигаясь вниз по потоку отношений слияния к ветке с наибольшим количеством изменений. Кроме того, если вы начали с Dev, вы бы создали отношения слияния между Dev › Main и Dev › Release, но не Main › Release. - person Jansen McEntee; 28.12.2018
comment
Спасибо за помощь. Получил это работает. В итоге я сделал необоснованное слияние, используя последний объединенный набор изменений. Это сделало мой список для объединения чертовски короче, и я смог объединить некоторые из них в группы. Потерял некоторую историю, сделав это, но не слишком беспокоился (хорошо, держите архивную копию). У меня все еще есть куча небольших проектов, в которых я, скорее всего, буду использовать исходный набор изменений ветки, но это был большой - person pinkfloydx33; 28.12.2018