我对 Subversion 和 Subclipse 都很陌生，并且看到一些问题让我相信更新到 head 和同步之间存在差异。具体来说，我发现当我尝试还原（使用子剪辑历史）时，我经常收到一条消息，说“无法从路径自己的未来历史中反向合并范围，请先尝试更新”。我的同步应该确保我在 REPO 上的分支中拥有所有文件的“头”版本，但是执行“更新到头”确实可以解决问题……那有什么好处呢？我试图检查 SVN 控制台以查看发生了什么变化，但它不是很冗长。
想法？
我有第二个问题，但我假设第一个问题的答案会阐明这一点。如果你好奇并有时间阅读，我也会把它打出来。这是场景......我已经从“生产”标签中分支了我的所有文件，并开始处理我的项目。几次提交后，我检查了更改文件的历史记录，并注意到“粗体”版本（根据文档，这应该是头部）低于我的所有提交。就好像我拥有的不是头。但是 head 只是项目的最新版本，对吧？所以我错过了什么。
感谢您的回复并花时间阅读本文！
它们是有区别的。当您使用同步视图时，仅更新视图中的项目。使用 Subversion，文件夹也有一个修订版，每次修改一个子版时都会增加一个修订版。但是，由于这些不会出现在视图中，因此它们永远不会更新。当您对项目执行团队 > 更新时，所有文件夹和文件都会更新为一个统一的修订版本。我有几篇博客文章解释了这一点：
这解释了混合修订工作副本的核心 SVN 概念，对于理解这一点至关重要：
http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html
第二个显示了 Subclipse 中的一个功能来处理这个问题：
http://markphip.blogspot.com/2006/12/subclipse-synchronize-feature-show-out.html
自从写了第二篇博客以来，大多数 Subclipse 用户发现他们不喜欢这个功能，即使它有助于解决这个问题。所以现在在当前版本中默认关闭。我认为没有人再使用它了。
最主要的是偶尔在您的项目上使用 Team > Update 以将其全部升级为一个统一的修订版本。
标记
我认为您认为同步与更新到 HEAD 相同的假设是错误的。如果用 Subclipse 的说法，“同步”意味着“提交”，那么它肯定是错误的，因为提交不会更新您的工作副本。在您承诺成为 HEAD 之后，您必须明确更新。
这让我想到了你的第二个问题：我认为粗体线低于其他提交的原因是由于上述原因——提交不会更新。这意味着您可以提交对文件的更改，然后查看另一个文件并认为它比 HEAD 更旧，因为其他文件还没有被带到 HEAD。
本文可能有助于澄清混合修订的概念：http: //markphip.blogspot.com/2006/12/mixed-revision-working-copies.html
我还鼓励您熟悉SVN 文档，因为当您了解底层 SVN 系统的工作原理时，使用 Subversion 的插件和扩展总是会变得更容易。