Mercurial Subrepos, как контролировать, какую ревизию я хочу использовать для subrepo?

Question

Я читаю подпункты и выполняю некоторые тесты локально, похоже, пока работает нормально, но у меня есть один вопрос.

Как мне указать / контролировать, какую ревизию я хочу использовать для определенного подпредложения?

Например, допустим, у меня есть два следующих проекта:

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

Теперь я хочу, чтобы библиотека классов была частью моего приложения, но из-за незрелости самой длинной ветви (которая заканчивается как четвертый коммит), я хочу временно использовать подсказку "второй коммит".

Как мне настроить это, предполагая, что это даже возможно?

Вот пакетный файл, который устанавливает два вышеупомянутых репозитория + добавляет библиотеку как подпункт.

Если вы запустите командный файл, он выдаст:

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

Как вы можете видеть из этой последней строки, он проверяет содержимое файла в библиотеке классов, то есть "v4" из четвертого коммита. Мне бы хотелось, чтобы оно было "v2" и сохранялось как "v2", пока я не буду готов вытащить более новую версию из хранилища библиотеки классов.

Может кто-нибудь сказать мне, можно ли делать то, что я хочу, и если да, что мне нужно сделать, чтобы привязать мой подотчет к нужной ревизии?

Batch-файл:

@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 == и перезапустил это, и теперь он блокирует вложенный репозиторий к правильной ревизии.

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

Answer 1

Ваша ревизия суб-репо не будет продвинутой без вашего явного выбора, поэтому все, что вам нужно сделать, это настроить ее так, как вам хотелось бы изначально. При первоначальном создании дополнительного репо, просто используйте аргумент -r, чтобы клонировать только те изменения, которые вам нужны:

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

обратите внимание на модификацию в третьей строке.

Answer 2

Не проверено, но вы должны иметь возможность перейти в свой подпункт, обновить его содержимое до нужного коммита (hg update), вернуться на один уровень вверх (в основном проекте) и зафиксировать.
Это должно обновить .hgsubstate с правильным коммитом.

(экстремальный обходной путь, обновить это .hgsubstate себя , но это не рекомендуется.)

Идея hg subrepos (или подмодулей Git) заключается в том, чтобы разрешить управление зависимостями, ссылаясь на fixed id для данного суб-репо.Если при создании подотчета идентификатор не указан, то выбирается последний идентификатор (v4 в вашем случае), но вы можете получить любой нужный вам идентификатор.

На самом деле, этот поток даже жалуетсячто:

В данный момент commit рекурсивно пытается зафиксировать вложенные репозитории перед фиксацией текущего репозитория.

Это позволяет:

• записывать некоторые изменения в суб-репо.
• обновлять .hgsubstate основного проекта новымсостояние (id) подпункта.