Слияние удалений в необоснованном объединении Team Foundation Server - PullRequest
Новая
       14

Слияние удалений в необоснованном объединении Team Foundation Server

3 голосов
/ 11 сентября 2009

У меня есть две ветви TFS, которые не имеют прямых родительских / дочерних отношений в TFS. В определенной ревизии, 94 в моем примере, несколько элементов были удалены. Мне было поручено применить эти удаления к основной ветке. Я хотел бы сделать это путем необоснованного слияния. Я попробовал следующую команду, чтобы сделать это: 

tf merge /baseless /recursive /version:94 .\programs\program1 ..\Release\programs\program1

Большинство элементов в дереве были помечены как «слияние», а некоторые были помечены как «слияние редактирования». Однако ни один из пунктов не был удален в месте назначения. По какой-то причине я попытался объединить одно удаление следующим образом: 

tf merge /baseless /recursive /version:94 .\programs\program1\source1.cs ..\Release\programs\program1\source1.cs

Я получил следующее сообщение об ошибке: 

The item [TFS_PATH] does not exist at the specified version.

Как мне это сделать? Есть ли способ избежать всех этих удалений сам?

Ответы [ 3 ]

2 голосов
/ 11 сентября 2009

Нет, извините, не может быть сделано. Необоснованное слияние очень глупо, составляя чуть больше, чем «взять содержимое папки и скопировать ее в другое место». Как следует из названия Baseless, нет никакой исторической информации, с которой можно было бы провести сравнение. На практике это означает, что содержимое файла распространяется, но не изменяется пространство имен (удаляет, восстанавливает, переименовывает). Вы можете сортировать содержимое файла своего рода, сопоставляя одинаковые имена файлов и скрещивая пальцы, но для определения пространства имен действительно необходимо знать, как выглядит древовидная структура в прошлый раз, когда ветви синхронизировались, поэтому TFS даже не беспокоится.

Тем не менее, если вы знаете номер набора изменений, в котором были сделаны желаемые удаления, составление сценария удаления самостоятельно - не важная вещь. 

$tfs = Get-TfsServer -path . -all
$deletes = get-tfschangeset 94 | % { $_.changes } | ? { ($_.changetype -band $tfs.VCS_ChangeType::delete) -ne 0 } | % { $_.serveritem }
($deletes -replace "$/branch1" "$/branch2") | Add-TfsPendingChange -delete

[не проверено, но должно работать]

2 голосов
/ 10 мая 2010

Я немного поэкспериментировал, и вот моя версия выше. кажется, работает для меня: 

get-tfsChangeset xx |% {$_.changes} |? {($_.changetype -band $tfs.VCS_ChangeType::delete) -ne 0 } |% {$_.item.serverItem -replace "\$/branch1","$/branch2"} |  Add-TfsPendingChange -delete

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

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

$sourcePath="\$/MySourcePath"
$destPath="$/MydestPath"

 Get-TfsItemHistory ./*.sql -r -IncludeItems  | %{$_.changes} |
 ? {($_.changetype -band $tfs.VCS_ChangeType::delete) -ne 0 } |
 % {$_.item.serverItem -replace $sourcePath,$destPath} |  Add-TfsPendingChange -delete
1 голос
/ 11 сентября 2009

Документация Patterns & Practices подразумевает, что вы должны разрешить конфликты слияния самостоятельно, один раз. (Предостережение: я не пробовал это.)

РЕДАКТИРОВАТЬ: P.S. См. Также Утро после безосновательного слияния TFS .

...