Mercurial Subrepos，如何控制我要用于子仓库的变更集? [英] Mercurial Subrepos, how to control which changeset I want to use for a subrepo?

问题描述

我正在阅读subrepos，并且已经在本地运行了一些测试，到目前为止似乎还可以，但是我有一个问题.

I am reading up on subrepos, and have been running some tests locally, seems to work OK so far, but I have one question.

如何指定/控制要用于特定子仓库的变更集?

How do I specify/control which changeset I want to use for a particular subrepo?

例如，假设我有以下两个项目:

For instance, let's say I have the following two projects:

class library                    application
o    fourth commit               o   second commit, added a feature
|                                |
o    third commit                o   initial commit
| 
| o  second commit
|/
o    initial commit

现在，我希望将类库作为应用程序的子存储库，但是由于最长分支(最终以第四次提交结束)的不成熟性，我想暂时使用第二次提交"技巧.

Now, I want the class library as a subrepo of my application, but due to the immaturity of the longest branch (the one ending up as fourth commit), I want to temporarily use the "second commit" tip.

假设有可能，我该如何进行配置?

How do I go about configuring that, assuming it is even possible?

这是一个批处理文件，用于设置上述两个存储库+将库添加为子存储库.

Here's a batch file that sets up the above two repos + adds the library as a subrepo.

如果运行批处理文件，它将输出:

If you run the batch file, it will output:

[C:\Temp] :test
...
v4

正如您从那里的最后一行看到的那样，它会验证类库中文件的内容，该文件的内容是第四个提交的"v4".我希望它是"v2"，并保持为"v2"，直到我准备从类库存储库中提取新版本为止.

As you can see from that last line there, it verifies the contents of the file in the class library, which is "v4" from the fourth commit. I'd like it to be "v2", and persist as "v2" until I'm ready to pull down a newer version from the class library repository.

有人可以告诉我是否有可能做我想做的事情，如果可以的话，我需要做些什么才能将子仓库锁定在正确的变更集上?

Can anyone tell me if it is possible to do what I want, and if so, what I need to do in order to lock my subrepo to the right changeset?

批处理文件:

@echo off
if exist app rd /s /q app
if exist lib rd /s /q lib
if exist app-clone rd /s /q app-clone


rem == app ==
hg init app
cd app
echo program>main.txt
hg add main.txt
hg commit -m "initial commit"
echo program+feature1>main.txt
hg commit -m "second commit, added a feature"
cd ..

rem == lib ==
hg init lib
cd lib
echo v1>lib.txt
hg add lib.txt
hg commit -m "initial commit"
echo v2>lib.txt
hg commit -m "second commit"
hg update 0
echo v3>lib.txt
hg commit -m "third commit"
echo v4>lib.txt
hg commit -m "fourth commit"
cd ..

rem == subrepos ==
cd app
hg clone ..\lib lib
echo lib = ..\lib >.hgsub
hg add .hgsub
hg commit -m "added subrepo"
cd ..

rem == clone ==
hg clone app app-clone

type app-clone\lib\lib.txt

---

编辑:好的，我知道了，谢谢 @VonC ，我添加了rem == clone ==行上方的批处理文件的下一部分，然后重新执行它，现在它将子存储库锁定到正确的变更集.

---

Edit: Ok, I got my answer, thanks @VonC, I added the following section to my batch-file, above the rem == clone == line, and re-executed it, and now it locks the subrepo to the correct changeset.

rem == lock ==
cd app\lib
hg update 1
cd ..
hg commit -m "lock to second commit"
cd ..

推荐答案

未经测试，但您应该可以进入子仓库，将其内容更新为正确的提交(

Not tested, but you should be able to go within your subrepo, update its content to the right commit (hg update), go back up one level (in the main project) and commit.
That should update the .hgsubstate with the right commit.

(极端的解决方法，自己更新.hgsubstate ，但不建议这样做.)

(extreme workaround, update that .hgsubstate yourself, but that is not recommended.)

hg子存储库(或Git子模块)的全部想法是允许进行依赖项管理通过引用给定子仓库的 fixed id.如果在创建子仓库时未提供ID，则选择最新的ID(在您的情况下为v4)，但是您可以签出所需的ID.

The all idea of hg subrepos (or Git submodules) is to allow a dependency management by referencing a fixed id for a given sub-repo. If no id is given when creating the subrepo, then the latest id is selected (v4 in your case), but you can checkout whatever id you need.

实际上，此线程甚至抱怨:

现在，commit递归地尝试在提交当前存储库之前提交子存储库.

Right now, commit recursively tries to commit subrepositories before committing the current repository.

这使您可以:

• 在子仓库中记录一些更改.
• 使用子存储库的新状态(id)更新主项目的.hgsubstate.

这篇关于Mercurial Subrepos，如何控制我要用于子仓库的变更集?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！