настройка ртутных / печных подчиненных на osx - PullRequest
0 голосов
/ 14 января 2012

Я пытался следовать инструкциям в ответе на на этот вопрос , используя печь.

Я хотел бы иметь возможность организовать вещи следующим образом:

  • /somepath/thirdparty отображается в хранилище печи "Thirdparty" и содержит различный код
  • /somepath/common отображается в хранилище печи "common" и содержит общий код, который я написал

и

  • /somepath/project1 соответствует хранилищу печи "project1"
  • /somepath/project1/thirdparty карты для филиала третьей стороны выше
  • /somepath/project1/common соответствует общей ветви выше

и

  • /somepath/project2 отображается в хранилище печи "project1"
  • /somepath/project2/thirdparty сопоставляет другую ветвь третьей стороны выше
  • /somepath/project2/common соответствует другой общей ветке выше

Я обнаружил, что когда я создал файл .hgsub в соответствии с инструкциями и добавил / отправил его в Kiln, я больше не мог просматривать файлы Kiln в средстве просмотра веб-файлов Kiln - он отображал скрытое сообщение о «перегреве» Kiln :-) Кроме того, хотя подпапки автоматически создавались в нужном месте, они не были заполнены файлами (возможно, из-за сбоя извлечения).

Кто-нибудь пробовал что-то подобное раньше, используя печь?

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

1 Ответ

2 голосов
/ 14 января 2012

Kiln в настоящее время не поддерживает вложенные операции, которые используют вложенные URL-адреса на сервере . Это означает, что вы не можете использовать оба следующих URL:

http://server/kiln/somepath/project1
http://server/kiln/somepath/project1/thirdparty

Таким образом, вы должны настроить Kiln так, чтобы у вас было четыре хранилища на сервере:

http://server/kiln/somepath/project1
http://server/kiln/somepath/project2
http://server/kiln/somepath/thirdparty
http://server/kiln/somepath/common

Это просто - всего четыре нормальных репозитория. Затем клонируйте «project» и создайте файл .hgsub с:

thirdparty = http://server/kiln/somepath/thirdparty
common = http://server/kiln/somepath/common

Когда вы вернете это обратно в Kiln, он заметит и отобразит ссылки для под-репозиториев. Тем не менее, вложенные репозитории не будут в конечном итоге будут вложены в сервер. Так что на сервере не будет никакого пути project1/thirdparty.

Также далеко не ясно, чего бы вы хотели. Когда у вас есть несколько проектов, которые сотрудничают и используют некоторую общую кодовую базу, вы хотите, чтобы «project1» и «project2» получали изменения друг друга в эту общую кодовую базу. Так что очень полезно, чтобы подпункт common в обоих проектах выдвигался из http://server/kiln/somepath/common.

В Mercurial мы обычно рекомендуем использовать пути вида common = common в файле .hgsub. Это означает, что сервер должен поддерживать вложенные репозитории. Когда Kiln не поддерживает вложенные репозитории, вы можете вместо этого использовать полные пути.

Когда вы изначально настраиваете подпапки, то помните, что вам нужно обновить их вручную. Таким образом, с указанными выше URL вы должны настроить «project1», запустив:

$ hg clone http://server/kiln/somepath/project1
$ echo "common =     http://server/kiln/somepath/common" > .hgsub
$ echo "thirdparty = http://server/kiln/somepath/thirdparty" > .hgsub
$ hg commit -m "Created subrepos"

Это создает начальные пустые подпапки. Они пусты, потому что вы не сказали Mercurial, какая ревизия вам нужна. Это отслеживается в .hgsubstate, где вы найдете:

0000000000000000000000000000000000000000 common
0000000000000000000000000000000000000000 thirdparty

Для заполнения под-репозиториев вы делаете

$ cd common
$ hg pull --update
$ cd ../thirdparty
$ hg pull --update
$ cd ..
$ hg commit -m "Updated subrepos"

Это обновляет 000... строк в .hgsubstate текущими идентификаторами наборов изменений наконечника для двух подпунктов. Будущие клоны «project1» заметят файл .hgsubstate и обязательно обновят вложенные версии до упомянутой там ревизии.

...