Mercurial忽略的文件在尝试更新到以前的版本时导致中止

以下是我的场景：当我最初创建Mercurial repo时，我使用

hg add

将所有*.pl*.sh和*.sql脚本添加到repo中。我后来学习了如何使用.hgignore文件从repo中排除其他文件。我需要排除的文件之一是*.sql文件，它是由脚本生成的，因此它本质上是一个数据文件，在脚本运行时会不断更改，从而生成它；因此，在几次修订之前，我明确地将其添加到了.hgignore文件中

今天，我想更新到将此*.sql文件添加到.hgignore之前的先前版本，以便我可以创建它的分支。但是，当我尝试将工作目录更新到此早期版本时，出现以下错误：

a.sql:未跟踪的文件不同
中止：工作目录中未跟踪的文件与请求修订版中的文件不同

我知道解决这个问题的一种方法是在尝试更新到以前的版本之前删除该文件，可以手动删除它，也可以使用

hg update--clean--check

这在这种特殊情况下可能会起作用，因为每次文件都是由脚本自动生成的，所以我不关心当前文件中的数据

然而，我试图找出当人们决定忽略一个文件集（比如一组不是自动生成的数据文件）并且需要返回到以前的版本，然后才被标记为忽略时，通常处理这种情况的安全方法是什么，特别是如果他们希望保留这些文件集中的最新内容，同时仍然能够查看Mercurial正在积极跟踪的文件的早期版本

我也考虑过你可以备份这些文件，但我认为如果这是一次性的，这是唯一合理的解决方案。如果您希望能够频繁地对以前的修订版进行

hg更新

，那么在每次更新到以前的修订版之前备份数据就变得相当乏味了（这也不是保证其他人不会删除repo中未跟踪的数据的可靠方法）

谢谢你的帮助

然而，我试图找出当人们决定忽略一个文件集（，如一组非自动生成的数据文件）并需要返回到以前的修订版，然后才标记为忽略时，通常处理这种情况的安全方法是什么，尤其是如果他们希望保留这些文件集中的最新内容，同时仍然能够查看Mercurial正在积极跟踪的文件的早期版本。

视情况而定

如果您对该存储库拥有独占控制权，并且具有要求所有人从中重新克隆的实际能力，则可以使用从旧版本中排除文件。这是迄今为止最干净的选项，但它将更改这些修订及其所有拓扑后代的修订标识符（哈希）。这就是为什么每个人都必须重新克隆；它们的旧克隆将无法与新存储库正常交互

如果你不能做到这一点，你可以将文件复制到其他地方（你已经有备份了，对吗？），用旧版本替换原始文件，然后从副本中还原它们。无论何时签出文件，都必须执行此操作，因此这肯定是次优的。通过将文件保存在存储库之外并签入到文件的符号链接，您可能可以稍微简化这一过程，但在签出旧版本时，您仍然需要修复符号链接

然而，您所描述的不是Mercurial的正常用例。通常，未跟踪的文件是自动生成的，或者至少能够从跟踪的文件中重新生成。操作假设是未跟踪的文件并不重要，可以随时丢弃。Mercurial实际上并没有这样做，因为这样做是不礼貌的，但当（例如）您创建了一个存储库包时，Mercurial也并没有做出任何特别的努力来保存它们

如果需要处理对象文件的版本控制，通常将它们存储在单独的工件存储库或其他系统中。这可能更难管理，因为在构建时必须将二进制文件与源代码重新结合起来。但它比将二进制文件松散地保存在存储库中并希望它们不会被意外覆盖或删除要健壮得多

---

另一种选择是将二进制文件折叠为文本，然后将文本置于版本控制下。这始终是可能的（例如，获取一个hextump），但可能是可行的，也可能不是合理的，这取决于文件格式。对于压缩文件格式（例如tarballs、大多数图像文件等），hextump不会比原始二进制文件更容易进行三路合并，因此它没有什么意义。类似地，如果二进制文件很大，hextump也会很大。另一方面，如果二进制文件是从源代码编译而来的，那么存储源代码并丢弃二进制文件是完全正常的。对于类似SQLite数据库的结构，您可以尝试存储一个SQL脚本来生成数据库。对于zip文件或tarball，存储内容。等等无论何时签出内容，都可以使用

make

或类似的工具重新生成所有这些内容，并且您可以使用自动化工具来实现自动化。

您找到解决方案了吗？