在解决方案中重命名文件夹和项目后，合并的效果如何？

解决方案

回答

以我的经验，只要我们在SourceControlExplorer(TFS)中进行所有重命名，TFS便可以跟踪重命名。

当我们在其他人进行大量重命名/移动而其他人正在编辑重命名的版本时，当其他人对原始文件进行更改时，就会出现问题。

在可能的情况下，我想说的是，如果我们要进行大规模的重命名和移动，则值得通知队友，并且如果可能的话，请他们推迟进行更改，直到我们签入。

与所有分支/合并问题一样，该问题可以通过很少的签入和合并来大大减少。

回答

在文件删除/重命名方面，TFS 2005取得了许多成功，但有一些非常特殊的例外，即：

• 在源分支和目标分支中都已重命名的文件(通常可以通过单击"忽略服务器更改"来轻松解决)；
• 在目标分支中已重命名但在源分支中已删除的文件。我记得有一种情况，无论我们尝试什么操作，合并都不会起作用，并且我们被迫"恢复"源分支上的更改，并在合并后重新执行。

据说TFS 2008解决了很多这样的问题，但是老实说，除了偶尔的合并问题外，TFS是稳定的，并且层次合并比使用SVN更加简单快捷。

回答

我们在TFS 2005中遇到了很多问题，通常都会删除。我尚未确定原因，但是我的许多团队成员在合并涉及重命名或者删除文件夹的更改时遇到了问题。如果在发生重命名的分支中进行了大量的重构(以及重命名和重新命名)，这似乎尤其正确。我还没有弄清楚原因或者复制步骤，因为我没有亲自参与过任何行不通的情况。

我还看到了其他一些一般的删除问题，例如：
分支A中的1，将子目录1中的权限减少为只读
2.创建分支B(从A分支到B)(签入)
3.删除分支B(签入)
4.从A创建一个新分支，为其命名与分支B相同
5.获得与TFS相关的奇怪的权限错误，该错误仍"看到"已删除分支B上的只读权限。

我们发现避免这种情况的唯一方法是插入步骤2a：将Branch B重命名为_B B(签入)

总的来说，TFS对我们来说很棒，但是在删除，重命名和合并方面还是有些麻烦。我们希望很快升级到2008年，我希望它能解决我们的问题。

回答

我在TFS 2008上有过大量文件和文件夹移动的经验。这样做是为了使我们的源代码结构更一致。我要做的就是在Team Explorer中拖放(并等待)，然后提交更改。