1

有人（除了我自己）不小心删除了 TFS 中的文件并将其签入。然后他发现了自己的错误并想替换丢失的文件，他这样做了 - 从他自己的硬盘驱动器中。在他的错误和我发现它之间，其他人对相邻文件进行了更改。现在，我想将已删除的文件回滚到删除之前的状态，但是当我尝试时，我在（如果我理解正确的话）原始文件和他的替换文件之间出现文件名冲突错误。

我无法回滚整个项目，因为已经完成了其他工作，我只想让这些文件恢复到“之前”的状态。

有没有人遇到过这个问题并解决了？或者没有解决办法。

4

3 回答 3

1

谢谢大家的意见。为了将来参考，这就是我最终解决此案的方式：

首先，我获取了该文件的本地副本。

然后在源代码管理资源管理器中，我将包含该文件的文件夹回滚到旧文件已被删除但新文件尚不存在的变更集中。我取消删除文件并签入，从而“从远处”带回原始文件。

之后，几乎是将我的本地副本和恢复的文件放入差异工具（我使用 BeyondCompare BTW）并更正恢复的文件以匹配新版本的情况。

我可以这样做有几个原因，即：

  • 文件的删除和重新添加是在两个连续的变更集中完成的。
  • 恢复的文件和本地副本之间的差异“非常小”（即，一个添加的方法和另一个中的几个更改黑客）。

我不知道如果我们直到几周后才错过有问题的文件会发生什么，我们会对周围的代码进行一些更改。我也不知道对本地版本所做的任何实质性更改在可恢复性方面意味着什么。

于 2010-07-01T14:29:21.117 回答
0
  • 将您的解决方案回滚到另一个工作副本。
  • 从该工作副本中拉出已删除的文件并将它们重新放入当前工作副本
  • 将这些文件签入到当前项目中。

我在这里看到的唯一问题是，您可能会丢失已删除文件的历史记录。

于 2009-10-20T15:07:55.953 回答
0

听起来像是电动工具的工作。干得好：

$deletedFiles = 
    Get-TfsChangeset 12345| 
    % { $_.changes } | 
    ? { $_.changetype.tostring().contains("Delete") } |
    % { $_.item.serveritem }

$deletedFiles | 
    Add-TfsPendingChange -Delete | 
    New-TfsChangeset -Comment "Delete mistakenly re-added files"

$deletedFiles |    
    Get-TfsChildItem -Deleted |
    ? { $_.changesetid -eq 12345 } |
    # this bit of ugliness is required by a bug in the Power Tools
    % { "$($_.serveritem);X$($_.deletionid)" } | 
    Add-TfsPendingChange -Undelete |
    New-TfsChangeset -Comment "Undelete old files"

正如评论中提到的，在理想的 Powershell 世界中，最终管道中丑陋的字符串解析不应该是必需的。如果事情按预期工作，您可以删除该行（或等效地，将其替换为Select-TfsItem |）。不幸的是，Power Tools 似乎并没有像我预期的那样处理删除 ID。

无论如何，这个脚本应该按照你的要求做。笔记：

  • 将 12368 替换为用户意外删除文件的变更集
  • 如果需要，将第二个管道中的 delete + checkin 替换为 Destroy
  • 这不会恢复系统中的任何其他更改（包括 #12345 中的其他更改），只是导致文件名冲突的那些
于 2009-10-20T15:46:31.460 回答