这是我的场景:当我最初创建我的Mercurial仓库时,我使用hg add
将所有* .pl * .sh和* .sql脚本添加到仓库中。后来我学会了如何使用.hgignore文件从repo中排除其他文件。我需要排除的一个文件是由脚本生成的* .sql文件,因此它本质上是一个数据文件,当脚本运行时它会不断变化而产生它;因此,我在几个版本之前将它明确地添加到.hgignore文件中。
今天,我想在将* .sql文件添加到.hgignore之前更新到之前的版本,以便我可以创建一个分支。但是,当我尝试将工作目录更新为此先前版本时,我收到以下错误:
a.sql: untracked file differs
abort: untracked files in working directory differ from files in requested revision
我知道我可以解决此问题的一种方法是在尝试更新到先前版本之前删除该文件,方法是手动删除它或使用hg update --clean --check
。
这可能适用于这种特殊情况,因为文件每次都是由脚本自动生成的,所以我不关心当前在其中的数据。
然而,我试图找出当人们决定忽略文件集时(例如一组自动生成的数据文件),人们通常会处理这种情况的安全方式是什么?并且需要在标记为被忽略之前返回到先前的修订版,特别是如果他们想要保留这些文件集中的最新内容,同时仍然能够查看Mercurial正在跟踪的文件的早期版本。
我还认为你可以备份文件,但我认为这只是一个合理的解决方案,如果这是一次性的情况。如果您希望能够频繁地随心所欲地hg update
进行以前的修订,那么每次更新到早期版本之前备份数据变得非常繁琐(它也不可靠)保证其他人不会删除未在回购中跟踪的数据的方式。
感谢您的帮助。
答案 0 :(得分:0)
但是,我试图找出人们在决定忽略文件集时通常会处理这种情况的安全方式(就像一组不是自动的数据文件生成)并且需要在被标记为被忽略之前返回到先前的修订版,,特别是如果他们想要保留这些文件集中的最新内容,同时仍然能够查看文件的早期版本Mercurial正在积极跟踪。
取决于。
如果您拥有对此存储库的独占控制权,并且具有要求每个人从中重新克隆的实际能力,那么您可以使用hg convert
从旧版本中排除文件。这是迄今为止最干净的选项,但它将更改这些修订版本及其所有拓扑后代的修订标识符(哈希值)。这就是为什么每个人都必须重新克隆;他们的旧克隆将无法与新存储库正常交互。
如果你不能这样做,你可以将文件复制到其他地方(你确实已经备份了,对吗?),用旧版本破坏原件,然后从你的副本中恢复它们。每当你检查文件时都必须这样做,所以它绝对不是最理想的。您可以通过将文件保留在存储库外并将符号链接签入文件来使这更容易一些,但是每当您签出旧版本时,您仍然需要修复符号链接。
但是,您所描述的并不是Mercurial的正常用例。通常,未跟踪的文件是自动生成的,或者至少能够从跟踪的文件中重新生成。操作假设是未跟踪的文件不重要,可以随时丢弃。 Mercurial实际上并没有这样做,因为这样做很粗鲁,但是当你(例如)你创建一个存储库时,它也没有做出任何特别的努力来保存它们。
如果需要处理目标文件的版本控制,通常将它们存储在单独的工件库或其他系统中。这可能更难管理,因为在进行构建时必须使用源代码重新组合二进制文件。但它比保存二进制文件在存储库中松散并希望它们不会被意外覆盖或删除要强大得多。
另一种选择是将二进制文件折叠为文本,然后将文本置于版本控制之下。这总是可能(例如,取一个hexdump)但可能是也可能不实用或不合理,具体取决于文件格式。对于压缩文件格式(例如tarball,大多数图像文件等),hexdump不会比原始二进制文件更容易进行3向合并,因此其中没有什么意义。同样,如果二进制文件很大,则hexdump也会很大。另一方面,如果从源代码编译二进制文件,则存储源并丢弃二进制文件是完全正常的。对于像SQLite数据库这样结构化的东西,您可以尝试存储将生成数据库的SQL脚本。对于zip文件或tarball,请存储内容。等等。所有这些都可以使用make
或类似的工具重新生成,无论何时检查出来,您都可以使用repo hook自动执行此操作。