サブリポジトリとメインリポジトリの両方をリモートのホストにクローンするにはどのように指定するのがよいのでしょうか?

[ohira]

いつもお世話になっております。

おおひらです。

サブリポジトリとメインリポジトリの両方をリモートのホストにクローンするにはどのように指定するのがよいのでしょうか?

ホスト1からホスト2にリポジトリのクローンを行う場合に

通常のリポジトリではれば、ホスト1にログインして実行しても

ホスト2にログインして実行しても同じ様にクローン可能です。

ところがリポジトリがサブリポジトリを含んでいる場合には

ホスト2にログインして実行した場合にはサブリポジトリも含んで

全体がクローンされますが、ホスト1にログインしてクローンした場合には

メインのリポジトリしかクローンされないようです。

簡単な指定でサブリポジトリを含む全体をクローンすることはできないものでしょうか?

[Kaz Nishimura]

私の乏しい経験からすると、サブリポジトリーをクローンするには作業ディレクトリーのアップデートが必要なのではないかと思います。ホスト 2 から作業ディレクトリーをアップデートしない形でクローンを実行してみれば、この仮説が当たっているか確認できそうですね。

2015年8月7日(金) 10:52 ohira <shin....@gmail.com>:

--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには mercurial-ja...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[Katsunori Fujiwara]

藤原です。

2015年8月7日 22:27 Kaz Nishimura <kaz...@vx68k.org>:

> 私の乏しい経験からすると、サブリポジトリーをクローンするには作業
> ディレクトリーのアップデートが必要なのではないかと思います。ホス
> ト 2 から作業ディレクトリーをアップデートしない形でクローンを実
> 行してみれば、この仮説が当たっているか確認できそうですね。

現状の実装は、仰る通り、サブリポジトリのクローンは、「作業領域更新
の一環」として実施されています。

ですので:

> 2015年8月7日(金) 10:52 ohira <shin....@gmail.com>:
>>

>> サブリポジトリとメインリポジトリの両方をリモートのホストにクロー
>> ンするにはどのように指定するのがよいのでしょうか?

>>
>> ホスト1からホスト2にリポジトリのクローンを行う場合に
>> 通常のリポジトリではれば、ホスト1にログインして実行しても
>> ホスト2にログインして実行しても同じ様にクローン可能です。


>> ところがリポジトリがサブリポジトリを含んでいる場合には
>> ホスト2にログインして実行した場合にはサブリポジトリも含んで
>> 全体がクローンされますが、ホスト1にログインしてクローンした場合には
>> メインのリポジトリしかクローンされないようです。

「対象リポジトリの履歴情報の複製」に関しては、どちらの方向でクロー
ンしても同じ挙動ですが、作業領域更新を伴わない後者のケースでは、サ
ブリポジトリの複製は行われません。


host1 上での "hg clone" である前者:

@host1$ hg clone repo ssh://host2/cloned

に対して、等価な host2 上での（逆方向） "hg clone" は、作業領域複
製を抑止した以下のものになります。

@host2$ hg clone -U ssh://host1/path/to/repo cloned


>> 簡単な指定でサブリポジトリを含む全体をクローンすることはできな
>> いものでしょうか?

現状の基本機能の範囲で何とか頑張るのであれば:

- clone に引き続き "hg update" を実施

@host1$ hg clone repo ssh://host2/path/to/cloned && \
ssh host1 hg -R path/to/cloned update

mercurial-server 等を使ったホスティング先へのクローンのような
ケースでは、ssh 経由での任意のコマンド実行ができませんから、こ
の手は使えないでしょうねぇ。

- サブリポジトリを列挙＋個別に "hg clone" を実施

作業領域配下のサブリポジトリを列挙しようとした場合、現状で使用
できる機能は:

1. hg debugfileset "subrepo()"

- サブリポジトリ種別が不明なので、別途判定の必要がある

2. hg debugsub

- 出力が機械処理向けではないので、解析が少々面倒

いずれの場合も、サブリポジトリ配下の再帰的な列挙は行わないので、
再帰的な処理が必要なら、別途スクリプト上で再帰処理のためのルー
プを組む必要があります。

こちらは「簡単な指定」という要求には反する気もしますが……

今のところは、上記のような方法ぐらいでしょうか。


サードパーティ製拡張機能がアリなら onsub エクステンションを使うと
いう手も。多分これが一番簡単かな？

https://mercurial.selenic.com/wiki/OnsubExtension


なお、リポジトリホスティング等の運用も含めて考えた場合、サブリポジ
トリの利用には配慮すべき点がいくつかあります。

http://d.hatena.ne.jp/flying-foozy/20120526/1338047861 では、以下
の点について説明していますので、参考になれば幸いです。

- サブリポジトリ取得が update 契機である事
- ホスティング利用時の .hgsub の書き方／リポジトリ配置方法

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[ohira]

おおひらです

アドバイスありがとうございました。

 hg debugfileset "subrepo()" 、onsub エクステンションはとても便利そうですね。

私の乏しい経験からすると、サブリポジトリーをクローンするには作業ディレクトリーのアップデートが必要なのではないかと思います。ホスト 2 から作業ディレクトリーをアップデートしない形でクローンを実行してみれば、この仮説が当たっているか確認できそうですね。

 アップデートでサブリポジトリがクローンされていたのですね。

うまくできるときにはクローンの後、アップデートもしていたので、

クローンでクローンされているかと勘違いしていました。

 1. hg debugfileset "subrepo()" 

      - サブリポジトリ種別が不明なので、別途判定の必要がある 

サブリポジトリ種別とはなんでしょうか?

ホストa、ホストb、ホストcと三個のホストがあり

ssh での接続が

接続元 -> 接続先

b -> a, b -> c   OK

            c -> b  NG

なため、ホストbからの操作でサブリポジトリを含めて

クローンしたいのです。

現状のサブリポジトリの仕様だと

ホストcからホストbへsshできない場合にかなり不便なように思います。

自分で考えた手法は

案1.

ホストbからホストcにsshできるのだから、sshを使ったトンネルを

作成してホストcからホストbにsshできるようにする

案2.

ホストbからローカルのPCに一旦クローンして、ホストcにクローンする

案3

ホストbからサブリポジトリも個別にホストcにクローンする

案1は、今回の環境ではファイヤーウォールの設定も変更しなくては行けないなど

芋づる式にやることが増える感じで断念。

案2は、リポジトリのサイズが大きめなためローカルPCのディスクに入りきらず断念。

案3については、

元々ホストaのリポジトリをホストcにクローンしたかったのですが、

ホストaからホストbへのクローンの手間に比べてホストbから

ホストcへのクローンの手間が大幅に増えそうなので何か自分の

やり方が悪いとか見落としがあるのではないかと考えていました。

.hgsubstateの内容も整合性がとれなくなったりしそうだし、筋が

悪い感じする、、、

アドバイスいただいた、 

hg debugfileset "subrepo()" 、onsub エクステンション

を使えば案3の感じで割と楽に出来そうです。

(今までは別の少し不確実な方法でサブリポジトリのリストを生成していました)

onsub エクステンションはまだ試していませんが、いろいろ試してみます。

ありがとうございました。

 

[ohira]

サブリポジトリ種別とはなんでしょうか?

subversion  か mercurial かでしょうか

[Katsunori Fujiwara]

藤原です。

2015年8月10日 12:16 ohira <shin....@gmail.com>:

> hg debugfileset "subrepo()" 、onsub エクステンションはとても便利そうですね。
>
>> 私の乏しい経験からすると、サブリポジトリーをクローンするには作
>> 業ディレクトリーのアップデートが必要なのではないかと思います。
>> ホスト 2 から作業ディレクトリーをアップデートしない形でクローン
>> を実行してみれば、この仮説が当たっているか確認できそうですね。
>
> アップデートでサブリポジトリがクローンされていたのですね。
> うまくできるときにはクローンの後、アップデートもしていたので、
> クローンでクローンされているかと勘違いしていました。
>
>>> 1. hg debugfileset "subrepo()"
>>>
>>> - サブリポジトリ種別が不明なので、別途判定の必要がある
>
> サブリポジトリ種別とはなんでしょうか?

（既にお気付きのようですが）現行実装では、サブリポジトリとして
Mercurial/Git/Subversion を扱う事ができます。そのため、ユーティリ
ティスクリプト等を作成する際に、「汎用的」な実装を目指すのであれば、
サブリポジトリ種別を判定した上で、適切なコマンドを実行する必要があ
ります。

http://mercurial-users.jp/manual/hg.1.html#subrepos

運用上「Mercurial 以外は扱わない」のであれば、この点は気にしなくて
も結構です。

ちなみに、今回のようなケースであれば、Subversion 形式のサブリポジ
トリを検出した際に、エラーなり警告扱いが必要でしょうね。

> ホストa、ホストb、ホストcと三個のホストがあり
> ssh での接続が
> 接続元 -> 接続先
> b -> a, b -> c OK
> c -> b NG
> なため、ホストbからの操作でサブリポジトリを含めて
> クローンしたいのです。

ホスト a や c が、ファイアウォールの向こう側だったり、仮想環境上の
ものだったりする場合に、ありがちなケースですね。

このケースだと、a や c 契機で b から pull できないので、b 起点での
clone や push で駆動する必要があるのは確かです。


> 現状のサブリポジトリの仕様だと
> ホストcからホストbへsshできない場合にかなり不便なように思います。

"hg clone -S" 的機能の必要性は、私も理解できるのですが、現状の実装
ベースで実現した場合、何らかの理由で処理が中断された際に:

- "hg clone -S" を再実行すると、複製済みサブリポジトリに対する複
製再実施により「作成済み」エラーが発生してしまう

- かといって "hg push -S" を実行すると、複製未実施サブリポジトリ
において、「連携先不在」エラーが発生してしまう

という、非常に中途半端かつ復旧が面倒な状況になってしまいます。

この辺に対処するには:

- 既存の処理に色々手を入れて、"hg clone -S" が安全に再実行できる
ようにする

⇒ サブリポジトリ機能自体が「最後の手段(feature of last
resort)」扱いなので、あんまり頑張りたくないなぁ……

https://mercurial.selenic.com/wiki/Subrepository

- 再帰的なサブリポジトリの列挙(+ コマンド実行)が出来るようにして、
そちらで対処する

⇒ onsub エクステンションそのもの！

という感じなので、いまひとつ修正意欲が湧いてこないんですよねぇ（笑）

> 自分で考えた手法は
>
> 案1.
> ホストbからホストcにsshできるのだから、sshを使ったトンネルを
> 作成してホストcからホストbにsshできるようにする
>
> 案2.
> ホストbからローカルのPCに一旦クローンして、ホストcにクローンする
>
> 案3
> ホストbからサブリポジトリも個別にホストcにクローンする
>
>
> 案1は、今回の環境ではファイヤーウォールの設定も変更しなくては行けないなど
> 芋づる式にやることが増える感じで断念。
>
> 案2は、リポジトリのサイズが大きめなためローカルPCのディスクに入りきらず断念。
>
> 案3については、
> 元々ホストaのリポジトリをホストcにクローンしたかったのですが、
> ホストaからホストbへのクローンの手間に比べてホストbから
> ホストcへのクローンの手間が大幅に増えそうなので何か自分の
> やり方が悪いとか見落としがあるのではないかと考えていました。
> .hgsubstateの内容も整合性がとれなくなったりしそうだし、筋が
> 悪い感じする、、、
>
>
> アドバイスいただいた、
> hg debugfileset "subrepo()" 、onsub エクステンション
> を使えば案3の感じで割と楽に出来そうです。
> (今までは別の少し不確実な方法でサブリポジトリのリストを生成していました)
> onsub エクステンションはまだ試していませんが、いろいろ試してみます。
>
> ありがとうございました。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)