Re: [mercurial-ja:1261] largefiles エクステンション

[Katsunori Fujiwara]

藤原です。

2015年2月20日 19:13 ohira <shin....@gmail.com>:

> ラージファイルエクステンションの効果を確認しようと既存のリポジトリを
> コンバートしました。その後別のマシンから、コンバート前のリポジトリと
> コンバート後のリポジトリをクローンしてみたのですが、クローンにかかる
> 時間がほとんどかわりなくて、効果が感じられなかったのです。
>
> ファイルも存在しているし、機能していないようです。
> クローン時にはラージファイルは転送されないと思っていたのですが
> 間違っていますでしょうか?

"hg clone" の際に、--noupdate/-U 指定が「無い」場合は、作業領域に
最新リビジョンを取り出すために、"hg update" 相当が実施されるため、
結果としてラージファイルの転送が発生してしまいます。

履歴のみを転送したい場合は、"hg clone -U" を実行してみてください。


ファイル内容の転送契機は、「ラージファイル」扱いの有無によって、以
下のように変わります。

- 従来の形式: 履歴情報伝搬時に、履歴の一部として転送
- ラージファイル形式: 作業領域更新時で、個別に転送

例えば、一度登録したラージファイルが、以後変更を受けることが少ない
ような運用ケースで、"hg clone" (-U 無し) や "hg pull -u" を実行し
た場合は、上記両者の差異が小さくなるため、largefiles 併用の効果が
あまり感じられないかもしれません。特に、通信帯域が狭い場合は、転送
の I/O 待ち時間が支配的になりますので……

一方で、ラージファイル扱いのファイルが度々更新されるようなケースで
は、"hg clone" (-U 無し) や "hg pull -u" の際に:

- 履歴情報には、ハッシュ値のみが記録されているので、変更履歴の転
送は軽い

- 作業領域の更新では、最新版のみを取り出すので、途中経過の情報転
送が不要

という感じで、転送データの軽減が図れます。


largefiles の内部処理や挙動等に関しては、以下のエントリが参考にな
れば幸いです。

http://d.hatena.ne.jp/flying-foozy/20111219/1324284157

ちょっと古いエントリですが、基本的な原理等に関しては、この時点から
変更されていない筈です。


> 中央リポジトリ用サーバでコンバート
> escm% hg lfconvert --size 10 sps2.5-trunkDEV sps2.5-trunkDEV.auto
> initializing destination sps2.5-trunkDEV.auto

まずは、この時点で変換先リポジトリ sps2.5-trunkDEV.auto において
"hg manifest --all" を実施してみてください。

この時、".hglf/" で始まるファイルが列挙されるなら、ラージファイル
への変換自体は実施されています。


> ローカルマシンにクローン(コンバート後のリポジトリからクローン)
> [shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto
> destination directory: sps2.5-trunkDEV.auto
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 2 changesets with 51450 changes to 51447 files
> updating to branch default
> 51447 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 86.545u 33.677s 2:21.85 84.7% 24+168k 1392+159609io 165pf+0w
>
> ローカルマシンにクローン(コンバート前のリポジトリからクローン)
> [shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV
> destination directory: sps2.5-trunkDEV
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 2 changesets with 51450 changes to 51447 files
> updating to branch default
> 51447 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 84.598u 34.822s 2:50.44 70.0% 23+167k 812+159609io 3pf+0w
>
> 中央リポジトリ用マシンの~/.hgrc
> largefiles =

中央リポジトリ用マシン/ローカルマシン共に、hgrc の記載から
[extensions] が抜けているのは、単なる転載漏れですよね？


また、ちょっと気になるのが、largefiles 併用時の "hg clone" におけ
る作業領域更新において、出力される筈の "getting changed
largefiles" というメッセージが見受けられない点です。

下記を見るに、lfconvert 先からの clone でラージファイルが転送され
ているみたいではありますが、もしかして(当該ファイルを含めて)ラージ
ファイル扱いされていないのでは？

"hg manifest --all" 出力に
".hglf/setup/docs/js/tiny_mce/plugins/emojidocomo/img_org/f8db.gif"
は含まれていますか？

> ローカルマシンに対象ファイルがコピーされていました。
> [shin@faith] ~/tmp/sps2.5-trunkDEV.auto% file !$
> file setup/docs/js/tiny_mce/plugins/emojidocomo/img_org/f8db.gif
> setup/docs/js/tiny_mce/plugins/emojidocomo/img_org/f8db.gif: GIF image data,
> version 89a, 12 x 12


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

[ohira]

おおひらです。

ラージファイル扱いされていないようです。

hgrc の書き方が良くないのでしょうか。

中央リポジトリ

escm% cd sps2.5-trunkDEV.auto 

escm% hg manifest --all | fgrep hglf

ローカルリポジトリ

[shin@faith] ~/tmp/sps2.5-trunkDEV.auto% hg manifest --all | fgrep hglf

#hgrcはラージファイルに関係ある部分だけコピペしました。

2015年2月20日金曜日 21時01分35秒 UTC+9 FUJIWARA Katsunori:

[Katsunori Fujiwara]

藤原です。

2015年2月23日 12:20 ohira <shin....@gmail.com>:

> ラージファイル扱いされていないようです。
>
> hgrc の書き方が良くないのでしょうか。
>
> 中央リポジトリ
> escm% cd sps2.5-trunkDEV.auto
> escm% hg manifest --all | fgrep hglf

lfconvert の変換先リポジトリの時点で hglf ディレクトリ配下のファイ
ルが無いのであれば、変換対象の条件が合致していないのでしょう。


最初に投函されたメールによれば:

>> > 中央リポジトリ用サーバでコンバート
>> > escm% hg lfconvert --size 10 sps2.5-trunkDEV sps2.5-trunkDEV.auto

^^^^^^^^^^
>> > initializing destination sps2.5-trunkDEV.auto

lfconvert の --size オプションは "MB" 単位ですが、想定している対象
ファイルは 10MB を超えていますか？

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

lfconvert の --size オプションは小数点指定が可能なので (1) 0.001
≒ 1KB 等のより小さな値を指定するか、(2) 拡張子等によるファイル名
パターンで明示的に変換対象を指定してください。

大き目のテキストファイルが誤認されるのを防ぐ上では、パターンを明示
して変換する方が良いでしょうね。


変換対象ファイル名のパターン指定は、以下のいずれかが排他的に選択さ
れます。両方で指定があった場合は、コマンドライン指定「のみ」が採用
されます:

- lfconvert のコマンドライン引数による指定

$ hg lfconvert SRCREPO DSTREPO glob:*.bmp glob:*.gif .....

上記例では、シェルによるワイルドカード展開を回避するために、意
図的に "glob:" を付与していますが、「引用符で囲む」等の対処で
も良い筈です。

ファイル名パターン指定の詳細に関しては、"hg help patterns" も
参照してみてください。

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

- ユーザ毎設定ファイル等での [largefiles] セクションによる指定

変換元リポジトリ等の .hg/hgrc ファイルでの指定は、lfconvert 実
行時には無効となりますので、注意してください。

また、パターン指定がある場合でも、サイズによる変換閾値判定は必須＆
有効なままです (この辺はちょっと微妙な挙動の気がしますが……)。

厳密にパターン指定ベースで変換したい場合は、誤認を避けるためにも、
指定値を大きめにしてください。


> #hgrcはラージファイルに関係ある部分だけコピペしました。

上記はおそらく、以下の私の確認に対する返答だと思いますが:

>> > 中央リポジトリ用マシンの~/.hgrc
>> > largefiles =
>>
>> 中央リポジトリ用マシン/ローカルマシン共に、hgrc の記載から
>> [extensions] が抜けているのは、単なる転載漏れですよね？

挙動の妥当性／障害原因究明の際には、設定記述のセクション名は非常に
重要な意味を持ちます。設定ファイル内容を提示する際には、以下の様な
理由から、セクション名は省略しないようにしてください。

- 転載時に省略したのか、元から記載されていないのか、判断が付かない

- 後から ML アーカイブを読んだ人に対して、「適切な記述」に関する
誤解を与えかねない

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

[ohira]

おおひらです。

コマンドラインで指定するサイズを10から0.001に変更したところ

ラージファイルの扱いになりました。

しかし、plやphpもラージファイルの扱いになってしまっていて

望んでる状況とは食い違っていました。

hgrcのパターン指定が無視されているようです。

コマンドラインのサイズ指定が10のときもhgrcのパターンの指定は無効っぽいです。

希望する処理は

ファイルサイズではなくて拡張子で判断され hgrcでパターン指定できることです。

(コマンドラインにパターンを列挙するのは避けたいです)

コマンドラインに引数を書かずに実行すればhgrcの指定が効くような気がしますが

実際にはコマンドラインに旧リポジトリ、新リポジトリだけ指定して引数を書かないと

エラーメッセージが表示されてしまいます。それで、始めはplとかphpがラージファイル

扱いにならないように大きめのサイズ10を指定していました。

サイズ指定が無いとエラー

escm% hg lfconvert sps2.5-trunkDEV sps2.5-trunkDEV.auto2 

abort: minimum size for largefiles must be specified

escm% 

仕方なくサイズ指定しています(.php .pl なども含まれてしまう)

escm% hg lfconvert --size 0.001 sps2.5-trunkDEV sps2.5-trunkDEV.auto

initializing destination sps2.5-trunkDEV.auto

escm%

phpも含まれてしまう

escm% hg manifest --all | fgrep hglf  | head -1

.hglf/ESFW/UnitTest/Cool/lib/CartDbCardsEntity.php

escm% 

すいませんでした。カットした部分を含んだものは下のものです。

中央リポジトリ用のサーバのhgrc

escm% cat ~/.hgrc 

[ui]

username = est...@escm.dev.estore.co.jp

[extensions]

color =

graphlog =

hgext.convert=

rebase =

mq =

flow = ~/hgext/hgflow/src/hgflow.py

hgext.highlight =

largefiles =

[web]

[hostfingerprints]

github.com = d7:12:e9:69:65:dc:f2:36:c8:74:c7:03:7d:c0:b2:24:a9:3b:d2:33

bitbucket.org = 45:ad:ae:1a:cf:0e:73:47:06:07:e0:88:f5:cc:10:e5:fa:1c:f7:99

[largefiles]

patterns =

  *.bmp

  *.css

  *.dat

  *.db

  *.gif

  *.htc

  *.htm

  *.html

  *.jpeg

  *.jpg

  *.js

  *.png

  *.psd

  *.swf

  *.tmpl

  *.txt

escm%

ローカルリポジトリ用のPCのhgrc

[shin@faith] ~% cat ~/.hgrc

[ui]

username = shin ohira

merge = internal:merge

[extensions]

# hgsubversion = ~/hgsubversion/hgsubversion

flow = ~/hgext/hgflow/src/hgflow.py

#flow = ~/hgflow.py

mq =

color =

rebase =

hgext.convert=

graphlog = 

progress =

hgext.keyword =

patchbomb =

largefiles =

hggit = ~/hgext/hg-git/hggit

[largefiles]

minsize = 2

patterns =

  *.bmp

  *.css

  *.dat

  *.db

  *.gif

  *.htc

  *.htm

  *.html

  *.jpeg

  *.jpg

  *.js

  *.png

  *.psd

  *.swf

  *.tmpl

  *.txt

[tortoisehg]

ui.language = ja

[keyword]

* =

[email]

method = /usr/sbin/sendmail

to = oh...@estore.co.jp

from = oh...@estore.co.jp

cc = ''

[hostfingerprints]

github.com = d7:12:e9:69:65:dc:f2:36:c8:74:c7:03:7d:c0:b2:24:a9:3b:d2:33

bitbucket.org = 45:ad:ae:1a:cf:0e:73:47:06:07:e0:88:f5:cc:10:e5:fa:1c:f7:99

[flow]

autoshelve = yes

[shin@faith] ~% 

2015年2月23日月曜日 15時15分47秒 UTC+9 FUJIWARA Katsunori:

[Katsunori Fujiwara]

藤原です。

2015年2月23日 18:14 ohira <shin....@gmail.com>:

頂いた [largefiles] patterns 記述を見直していて気が付きました。

おそらく拡張子によるパターン指定が、**.bmp ではなく *.bmp 形式で記
述されているのが原因だと思われます。


[largefiles] patterns 指定でのデフォルト形式である glob は、現ディ
レクトリ相対 (lfconvert の場合は変換元ルート相対) なので、ディレク
トリ階層を跨げない * は、ルート直下のファイルにしか合致しません。

その一方で、** はディレクトリ階層を跨げます

「あれ？それじゃぁ hgignore の glob は何故機能するの？」と思われ
るかもしれません。

実は、hgignore での glob 形式は、「パスの任意の位置に対する部分一
致」を判定する形式で、コマンドラインでの glob 形式とは異なる挙動に
なっているのです。

この辺はなかなか紛らわしいのですが、後方互換性を重視する
Mercurial では、どちらかに統一されることは、おそらく無いでしょう
ねぇ。

一応、"hg help patterns" や "hg help hgignore" では、「備考」とし
て注意してほしい旨表示されます。実は、私自身がちょくちょく混乱して
いたので、提案して記述を盛り込んでもらったのですが(笑)

この辺のパターン指定の詳細に関しては、以下のブログエントリも参照し
てみてください。

http://d.hatena.ne.jp/flying-foozy/20140107/1389087728


パターン指定を行う場合は、変換元リポジトリのルート位置で、 files
コマンドを使うなどして、期待通りのファイルが対象として選択されるか
（＝ 指定パターンが期待通りに合致するか）を確認してみてください。

$ cd SRCREPO
$ hg files glob:*.bmp <<<< 対象ファイルが表示されない
$ hg files glob:**.bmp <<<< 対象ファイルが表示される


ちなみに、拡張子は全て小文字に統一されていますか？

Mercurial のデフォルト挙動は文字大小を区別「する」ので、Windows 環
境等の文字大小を無視する環境でファイルを追加するような場合は、ご注
意ください。

文字大小を無視したパターンの指定に関しては、以下のブログエントリが
参考になれば幸いです。

http://d.hatena.ne.jp/flying-foozy/20131124/1385283660

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

[ohira]

大平です。

hgrcのアスタリスクを一個から2個に修正することで

コンバートでラージファイルの機能の有効になりました。

10Mの最小ファイルサイズの指定も問題ありませんでした。

time hg lfconvert --size 10 sps2.5-trunkDEV sps2.5-trunkDEV.auto

中央リポジトリ用サーバでもローカルリポジトリ用PCでも

上のコマンドでコンバートが行われていることを確認しました。

ところが、中央リポジトリ側でラージファイルの機能を

有効にしたリポジトリをローカルリポジトリ用PCにクローンしようとすると

エラーになります。

コンバート前のリポジトリは問題無くクローンできています。

もしかして、ラージファイルを使ったリポジトリはクローン出来ない

仕様だったのでしょうか。

2015年2月23日月曜日 22時08分31秒 UTC+9 FUJIWARA Katsunori:

[ohira]

LOG==================

[shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV ; time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto

destination directory: sps2.5-trunkDEV

requesting all changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 51450 changes to 51447 files                            

updating to branch default

51447 files updated, 0 files merged, 0 files removed, 0 files unresolved        

86.122u 34.931s 2:43.86 73.8%   25+169k 78+159609io 105pf+0w

remote: abort: repository requires features unknown to this Mercurial: largefiles!

remote: (see http://mercurial.selenic.com/wiki/MissingRequirement for more information)

abort: no suitable response from remote hg!

0.145u 0.137s 0:00.84 32.1%     10+171k 0+0io 0pf+0w

[shin@faith] ~/tmp% 

2015年2月24日火曜日 19時01分18秒 UTC+9 ohira:

[Katsunori Fujiwara]

藤原です。

2015年2月24日 19:07 ohira <shin....@gmail.com>:

> 2015年2月24日火曜日 19時01分18秒 UTC+9 ohira:
>>
>> 大平です。
>> hgrcのアスタリスクを一個から2個に修正することで
>> コンバートでラージファイルの機能の有効になりました。

無事に変換できたようで何よりです。

>> ところが、中央リポジトリ側でラージファイルの機能を
>> 有効にしたリポジトリをローカルリポジトリ用PCにクローンしようとすると
>> エラーになります。
>>
>> コンバート前のリポジトリは問題無くクローンできています。
>>
>> もしかして、ラージファイルを使ったリポジトリはクローン出来ない
>> 仕様だったのでしょうか。

そんなことは無いですよ。

> remote: abort: repository requires features unknown to this Mercurial:
> largefiles!

エラーメッセージから見るに、アクセス先のリポジトリで largefiles エ
クステンションが有効になっていないだけだと思います。

largefiles エクステンションの有効化はどの方法で行っていますか？

(1) 対象リポジトリの .hg/hgrc
(2) ホームディレクトリ直下の .hgrc
(3) それ以外の設定ファイル (ホスト毎／インストール毎等)

> [shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV ; time hg

一番可能性が高いのが、リモートホスト (上記例だと escm) に対して:

- ssh ログインして「対話的」に作業する際のアカウント
(今まで頂いた実行例では記載なし)

- Mercurial の ssh 連携で使用するアカウント
(上記例だと hg)

上記のアカウントが異なるため、読み込まれる ~/.hgrc ファイルがそも
そも異なることから、largefiles が有効化されない、という状況ですね。


上記の連携先であれば、以下の様なコマンドを実行して、largefiles エ
クステンションが有効になっていることを確認してください。

$ ssh hg@escm hg -R sps2.5-trunkDEV showconfig --debug extensions

--debug をつけることで、どの設定ファイルを読み込もうとしているかも
表示されますから、想定しているものと合致しているか確認してみてくだ
さい。


あまり一般的な使い方ではありませんが、もしも、インストール毎設定ファ
イルで largefiles を有効化しているならば、非対話的 ssh 実行におけ
る初期化周りの問題で、引っ掛かっている可能性もあります

Linux ディストリビューションによっては、ssh での非対話実行の際に
は、~/.bashrc における環境変数初期化処理等を大幅にすっ飛ばすのが、
デフォルトになっている場合があります。

このような環境で、自分の固有設定を ~/.bashrc の末尾に書いていたり
すると、例えば PATH 環境変数等が思ったように設定されなかったりしま
す。

例えば、以下のようにログイン⇒対話的に実行した場合と:

@local $ ssh foo@remote
@remote $ which hg

実行コマンドを明示して、以下の様に非対話的に実行した場合では、
PATH 周りの設定の差から、異なる hg が実行される、といったケースが
あります。

@local $ ssh foo@remote which hg

Mercurial の ssh 連携では、非対話実行形式が使用されるので、対話形
式で期待通りの hg コマンドが実行されれているからと油断していると、
足元をすくわれることになります。

この辺の詳細に関しては、以下の情報も参照してみてください。

http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-books.html#thgbook.d.3.2


ちなみに、次のメジャーリリース 3.4 では、clone 先で largefiles 有
効化が必要となる場合は .hg/hgrc に自動的に有効化記述を追加する、と
いう処理が取り込まれる予定です。

http://selenic.com/repo/hg/rev/e1dbe0b215ae

しかし lfconvert に対しては、同等の処理が追加されていないみたいで
すので、利便性／相似性の点から、追加要望を提案してみますね。

この提案が取り込まれれば、clone/lfconvert 先での largefiles 有効化
絡みの問題は発生しなくなる筈です。

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

[shin ohira]

おおひらです。

すいません。

hg@escm のhgrcを修正するのを忘れていました。

もしかしたらとは思っていましたが

普段変更してないので見落としていました。

llkmn

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

[ohira]

おおひらです。

hg@escmの hgrcを修正して再度テストしました。

やはりクローン時にエラーが発生しました

[shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto

remote: abort: repository requires features unknown to this Mercurial: largefiles!

remote: (see http://mercurial.selenic.com/wiki/MissingRequirement for more information)

abort: no suitable response from remote hg!

0.167u 0.114s 0:00.84 32.1%     16+177k 0+0io 94pf+0w

[shin@faith] ~/tmp%

中央リポジトリ用サーバの hg@escm hgrcファイルの内容

[shin@faith] ~/tmp% ssh escm cat /usr/local/mercurial-server/.hgrc     

[extensions]

mq =

color =

rebase =

convert=

graphlog = 

progress =

keyword =

patchbomb =

largefiles =

[mq]

secret = true

[flow]

autoshelve = true

[keyword]

* =

[hooks]

pre-serve.tmpdir = python:hgenviron.settmpdir

ラージファイルに変換したリモートのリポジトリをクローンするテスト

[shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto

remote: abort: repository requires features unknown to this Mercurial: largefiles!

remote: (see http://mercurial.selenic.com/wiki/MissingRequirement for more information)

abort: no suitable response from remote hg!

0.141u 0.111s 0:00.79 31.6%     22+181k 0+0io 0pf+0w

アカウント

[shin@faith] ~/tmp% ssh escm fgrep mercurial-server /etc/passwd

hg:*:7802:7802:Mercurial repositories:/usr/local/mercurial-server:/bin/sh

hg@escm はmercurial-serverを使っているため

ssh でのテストはエラーになります

[shin@faith] ~/tmp% ssh hg@escm

PTY allocation request failed on channel 0

mercurial-server: direct logins on the hg account prohibited

Connection to escm.mxfw.net closed.

[shin@faith] ~/tmp% ssh hg@escm hg

mercurial-server: illegal command 'hg'

[shin@faith] ~/tmp% ssh hg@escm ls

mercurial-server: illegal command 'ls'

通常利用アカウントでの接続確認

[shin@faith] ~/tmp% ssh escm date

Wed Feb 25 13:24:49 JST 2015

[shin@faith] ~/tmp%

2015年2月24日火曜日 20時55分08秒 UTC+9 ohira:

FUJIWARA Katsunori(flying.foozy@gmail.com)

--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このトピックの登録を解除するには https://groups.google.com/d/topic/mercurial-ja/4XBLuOtlFzA/unsubscribe にアクセスしてください。

このグループから退会し、グループのすべてのトピックの登録を解除するには mercurial-ja+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。

[Katsunori Fujiwara]

藤原です。

2015年2月25日 14:25 ohira <shin....@gmail.com>:

> アカウント
> [shin@faith] ~/tmp% ssh escm fgrep mercurial-server /etc/passwd
> hg:*:7802:7802:Mercurial repositories:/usr/local/mercurial-server:/bin/sh

トラディショナルな UNIX 系 OS の /etc/passwd の場合、末尾から2つ目
のフィールドは、ホームディレクトリ位置ですから:

> hg@escm はmercurial-serverを使っているため
> ssh でのテストはエラーになります
> [shin@faith] ~/tmp% ssh hg@escm
> PTY allocation request failed on channel 0
> mercurial-server: direct logins on the hg account prohibited
> Connection to escm.mxfw.net closed.

- 「mercurial-server (という名前のディレクトリ)を使っている」こ
とと、「ssh で対話的なログインができない」ことには、相関性は無い

- ログインシェルとして、/bin/false や存在しないコマンドではなく、
/bin/sh が指定されているので、対話的ログインの禁止は、以下のい
ずれかで実施されている筈

- ~/.profile や ~/.login 等で明示的に判定
- .ssh/authorized_keys 等を使った ssh レベルでの禁止

「mercurial-serverを使っているため」は、どういった事象への言及を意
図されてます？

もしかして、「.ssh/authorized_keys の command 指定に
contrib/hg-ssh を使っている」の間違いではありませんか？

http://selenic.com/repo/hg/file/ff5caa8dfd99/contrib/hg-ssh#l12

contrib/hg-ssh の実装を見る限りでは、以下の実行例で表示されている
エラーメッセージとも合致します (sh や bash のコマンド不在時エラー
は概ね "not found") し:

> [shin@faith] ~/tmp% ssh hg@escm hg
> mercurial-server: illegal command 'hg'
> [shin@faith] ~/tmp% ssh hg@escm ls
> mercurial-server: illegal command 'ls'

上記のように、そもそも一般的なコマンドを直接実行できない状況でも:

> やはりクローン時にエラーが発生しました
> [shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto
> remote: abort: repository requires features unknown to this Mercurial:
> largefiles!
> remote: (see http://mercurial.selenic.com/wiki/MissingRequirement for more
> information)
> abort: no suitable response from remote hg!

ssh 連携による clone 処理の際に、上記のような段階 (＝ hg コマンド
が実行されて、且つ escm/sps2.5-trunkDEV.auto リポジトリの機能チェッ
クまで実行) に到達していることとも辻褄が合います。

少なくとも私の知る限りでは、Mercurial の公式配布物には
"mercurial-server" なる名称のものは存在しません。(rhodecode 等では
"mercurial-server" という名前が使われているのでしょうか？)

まずは、~hg/.ssh/authorized_keys ファイルの確認＆情報提供をお願い
します。


さて次に、~hg/.hgrc (= /usr/local/mercurial-server/.hgrc) での設定
が、期待通りに読み込まれない件ですが、「hg アカウントでのコマンド
実行の際に、HOME 環境変数が上手く設定されていない」という原因ぐら
いしか思い当たりませんねぇ。

$ env | grep HOME
HOME=/home/fujiwara
$ hg showconfig ui
ui.username=FUJIWARA Katsunori <fo...@lares.dti.ne.jp>

$ export HOME=
$ env | grep HOME
HOEM=
$ hg showconfig ui
※ ~/.hgrc の読み込みは発生しない

「.ssh/authorized_keys の command 指定に contrib/hg-ssh を使ってい
る」のであれば、一度 contrib/hg-ssh の変わりに env コマンドを指定
した上で、ssh を「非」対話的に実行してみてください。

@failth $ ssh hg@escm env | grep

HOME 環境変数が定義されていない場合は、以下のいずれかが原因と思わ
れます。

- シェルの初期化処理の記述が不適切

私の環境のオンラインマニュアル sh(1) を読む限りでは、シェル
実行時には、 必ず HOME 環境変数が設定される筈なので、ログイ
ンシェルが読み込む設定ファイルで、HOME を未設定にするような、
何らかの不適切な記述がある可能性があります。

今回の例で言えば、hg アカウントのである/bin/sh ~/.profile の
記述を確認してみてください。

- .ssh/authorized_keys の command で指定されるコマンドは、
HOME 環境変数設定なしで、sshd から直接実行される

オンラインマニュアル ssh(1) によれば、HOME 環境変数の設定は
ssh がやってくれる筈なので、この可能性は低いとは思いますが、
一応 (command 指定時固有の挙動なのかも？)

この場合の対処方法としては、.ssh/authorized_keys への記述に
environment="HOME=/usr/local/mercurial-server" のような指定
を追加する、とかですかねぇ。


なお、この辺の原因追求は、ssh 周りを色々確認しなければなりませんの
で、まずは以下の確認を優先してみた方が良い気がします。

1. ~/hg/escm/sps2.5-trunkDEV.auto/.hg/hgrc で largefiles を有効化

.hg/hgrc ファイルのオーナーが hg ユーザ以外だと、セキュリティ
上の観点から無視されるので、注意してください。

"hg help config" の trusted セクションの説明を参照してみてくだ
さい。

http://mercurial-users.jp/manual/hgrc.5.html#trusted

2. largefiles な ssh://hg@escm/sps2.5-trunkDEV.auto から clone
できることを確認

この時点で clone できないのであれば、ssh 周り以外の原因を探さない
と駄目ですから……

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

[ohira]

おおひらです。

「mercurial-serverを使っているため」は、どういった事象への言及を意 

図されてます？ 

もしかして、「.ssh/authorized_keys の command 指定に 

contrib/hg-ssh を使っている」の間違いではありませんか？ 

 mercurial-serverは公式のものではなくて、hg-sshと似たツールで

下のURLのものをインストールして使っているつもりです。

(hg-ssh, mercurial-serverの両方を試してからmercurial-serverを選んだので

もしかしたら現在動いてるのはhg-sshかもしれないと思って確認のつもりで

ディレクトリ名を調べました。ご指摘いただいた様に確認手法としては適切

ではないと思います)

http://www.lshift.net/work/open-source/mercurial-server/

    - .ssh/authorized_keys 等を使った ssh レベルでの禁止 

 そうです。

escm% sudo cat ~hg/.ssh/authorized_keys

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/local/share/mercurial-server/hg-ssh root/ohira/id_rsa.pub" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAy3+W1JSO4Z1g36HKhu6dudvy00YLXxNq44JaG+q6nY7XFljRunMMPQLTaFBCKQKBX3OEPbeQZ9snqzykORPQgthwCbBLJimcBQAUn0GiMzTYWQPmjOFEjbLiHW0D+e3NyfnglWrRYjZ3c9/tTaHB+Xvl7smHiK+4MO39AHgNX06ymTZKstbVtmt+GLEm+l555Muk86rrAXr33AhJQh/SeRGOUYTmD6a2nq0GQeKNLyy9OvGK871dk5MyxED+vnwsl6TqC8I5H1ShX8Cx+yKY1776fqn6jyQgpImjGJfuaqSYrCDAThp+9BjwV9EpOl4jCesyZfblNRpfIhJdYWhaZQ== shin@faith

なお、この辺の原因追求は、ssh 周りを色々確認しなければなりませんの 

で、まずは以下の確認を優先してみた方が良い気がします。 

  1. ~/hg/escm/sps2.5-trunkDEV.auto/.hg/hgrc で largefiles を有効化 

    .hg/hgrc ファイルのオーナーが hg ユーザ以外だと、セキュリティ 

    上の観点から無視されるので、注意してください。 

    "hg help config" の trusted セクションの説明を参照してみてくだ 

    さい。 

        http://mercurial-users.jp/manual/hgrc.5.html#trusted 

  2. largefiles な ssh://hg@escm/sps2.5-trunkDEV.auto から clone 

     できることを確認 

この時点で clone できないのであれば、ssh 周り以外の原因を探さない 

と駄目ですから…… 

 はい。

その部分から再確認します。

2015年2月26日木曜日 0時40分40秒 UTC+9 FUJIWARA Katsunori:

[ohira]

おおひらです。

リポジトリのディレクトリに hgrcを設置することで

ローカルのPCにクローンできるようになりました。

お手数をおかけいたしました。ありがとうございます。

設置したファイル

escm% cat /data/hg-repos/repos/sps2.5-trunkDEV.auto/.hg/hgrc

[extensions]

color =

graphlog =

hgext.convert=

rebase =

mq =

highlight =

largefiles =

[largefiles]

patterns =

  **.bmp

  **.css

  **.dat

  **.db

  **.gif

  **.htc

  **.htm

  **.html

  **.jpeg

  **.jpg

  **.js

  **.png

  **.psd

  **.swf

  **.tmpl

  **.txt

escm%

ローカルPCからのクローンの結果

[shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto

destination directory: sps2.5-trunkDEV.auto

requesting all changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 51450 changes to 51447 files                            

updating to branch default

getting changed largefiles                                                      

42259 largefiles updated, 0 removed

51447 files updated, 0 files merged, 0 files removed, 0 files unresolved

225.201u 60.796s 5:24.62 88.0%  7+167k 84+197779io 7pf+0w

ラージファイルの保管状況

[shin@faith] ~/tmp% cd sps2.5-trunkDEV.auto/

[shin@faith] ~/tmp/sps2.5-trunkDEV.auto% hg manifest --all | fgrep hglf | tail

.hglf/weblog/sales-report/day_zero_index.html

.hglf/weblog/sales-report/dot_or.gif

.hglf/weblog/sales-report/dot_tb.gif

.hglf/weblog/sales-report/dot_yg.gif

.hglf/weblog/sales-report/m_scale.gif

.hglf/weblog/sales-report/mon_index.html

.hglf/weblog/sales-report/mon_zero_index.html

.hglf/weblog/sales-report/scale.gif

.hglf/weblog/sales-report/week_index.html

.hglf/weblog/sales-report/week_zero_index.html

[shin@faith] ~/tmp/sps2.5-trunkDEV.auto% 

2015年2月26日木曜日 10時05分05秒 UTC+9 ohira:

[ohira]

おおひらです。

ラージファイルを使った場合と使わない場合で、中央リポジトリ用サーバから

ローカルPC上へのクローンの時間を調べてみました。

ラージファイルを使うと約3倍の時間がかかっています。

リポジトリ内のhgrcファイルの内容は最小限のものに変更しました。

hgrcの内容

escm% cat /data/hg-repos/repos/sps2.5-trunkDEV.auto/.hg/hgrc

[extensions]

largefiles =

escm%

ローカルPCへのクローン

[shin@faith] ~/tmp% time hg clone ssh://hg@escm/sps2.5-trunkDEV.auto ; time hg clone ssh://hg@escm/sps2.5-trunkDEV

destination directory: sps2.5-trunkDEV.auto

requesting all changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 51450 changes to 51447 files                            

updating to branch default

getting changed largefiles                                                      

42259 largefiles updated, 0 removed

51447 files updated, 0 files merged, 0 files removed, 0 files unresolved

225.123u 63.565s 5:51.16 82.2%  7+167k 96+197779io 0pf+0w

destination directory: sps2.5-trunkDEV

requesting all changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 51450 changes to 51447 files                            

updating to branch default

51447 files updated, 0 files merged, 0 files removed, 0 files unresolved        

84.920u 33.961s 2:53.55 68.4%   23+169k 4+159609io 0pf+0w

[shin@faith] ~/tmp%

2015年2月26日木曜日 15時19分43秒 UTC+9 ohira:

[Katsunori Fujiwara]

藤原です。

2015年2月26日 15:19 ohira <shin....@gmail.com>:

> リポジトリのディレクトリに hgrcを設置することで
> ローカルのPCにクローンできるようになりました。

無事にクローンできたようで何よりです。

残るは ~hg/.hgrc が読み込まれない件ですが:

>>> さて次に、~hg/.hgrc (= /usr/local/mercurial-server/.hgrc) での設定
>>> が、期待通りに読み込まれない件ですが、「hg アカウントでのコマンド
>>> 実行の際に、HOME 環境変数が上手く設定されていない」という原因ぐら
>>> いしか思い当たりませんねぇ。

[snip]

>>> 「.ssh/authorized_keys の command 指定に contrib/hg-ssh を使ってい
>>> る」のであれば、一度 contrib/hg-ssh の変わりに env コマンドを指定
>>> した上で、ssh を「非」対話的に実行してみてください。
>>>
>>> @failth $ ssh hg@escm env | grep

こちらの環境で試してみたところ、authorized_keys で command 指定し
た場合であっても、ssh による HOME 環境変数設定は実施されているみた
いですから、仮に HOME 絡みで問題があるとしても、
/usr/local/share/mercurial-server/hg-ssh スクリプト側の問題っぽい
ですねぇ。


サーバ側での通常作業には別のアカウントを使っているみたいですので、
もしかして ~hg/.hgrc のオーナー設定が hg 以外になっていませんか？

>>> .hg/hgrc ファイルのオーナーが hg ユーザ以外だと、セキュリティ
>>> 上の観点から無視されるので、注意してください。
>>>
>>> "hg help config" の trusted セクションの説明を参照してみてくだ
>>> さい。
>>>
>>> http://mercurial-users.jp/manual/hgrc.5.html#trusted

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

[Katsunori Fujiwara]

藤原です。

2015年2月26日 17:47 ohira <shin....@gmail.com>:

> ラージファイルを使った場合と使わない場合で、中央リポジトリ用サーバから
> ローカルPC上へのクローンの時間を調べてみました。
>
> ラージファイルを使うと約3倍の時間がかかっています。

最初の頃の返信でも書きましたが、largefiles エクステンションは:

- 履歴には、「ファイルの内容」ではなく、「ファイル内容のハッシュ
値＝40バイト文字列」のみを書き込むので、履歴容量 (＝転送性能の
主要因) を抑えられる

- ラージファイル扱いのファイルは、作業領域の更新時に転送される

という特徴を持っているので:

- 作業領域の更新を伴う転送 (-U 無しの clone や、-u 有りの pull )

作業領域更新のラージファイル転送により、履歴転送量の低減分が相
殺される可能性があります。

- ファイル毎の変更頻度が低い

履歴情報としての転送量と、(作業領域更新時の)ファイルの直接転送
量に、大きな差が付かないことになります。

通常ファイルは「履歴情報」として全体が一括転送される一方、ラー
ジファイルはファイル毎に「要求⇒転送」を都度繰り返すため、両者
の転送量の差が小さい場合は、転送手順上の待ちの分だけ遅くなる可
能性があります。

特に、対象ファイルのサイズがそれほど大きくない場合は、連携元／
先での都度ハンドシェイクの分で、転送量の低減が相殺されるでしょ
うねぇ。

上記の様な条件が成立する場合は、あまりメリットを享受できないと思わ
れます。

以上のことから、「バイナリファイルが結構ある ⇒ largefiles を使お
う！」というベストプラクティス的な類のものではないことを理解した上
で、特性を踏まえて使用する必要があります。

管理対象「ファイル」の特性 (テキストかバイナリか？) よりも、管理対
象「プロジェクト」の特性 (どのファイルがどういった契機・頻度・担当
で更新されるか？それを参照する際には、最新版のみで事足りるか？) の
方が、利用判断の基準になる気がします。

マージで衝突が発生した場合、現状の実装だと、通常ファイル扱いと比較
して、衝突解消に外部マージツール等を使えない、といった不便さもあり
ますし…… (これに関しては、機能拡張提案したいなぁ、と考えています)


[largefiles 時]

> added 2 changesets with 51450 changes to 51447 files

> 42259 largefiles updated, 0 removed
> 51447 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 225.123u 63.565s 5:51.16 82.2% 7+167k 96+197779io 0pf+0w

[非 largefiles 時]

> added 2 changesets with 51450 changes to 51447 files

> 51447 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 84.920u 33.961s 2:53.55 68.4% 23+169k 4+159609io 0pf+0w

上記実行例では、転送対象履歴が:

- リビジョン数: 51450
- ファイル数: 51447 (ラージファイル扱いが 42259 ≒ 82%)

という感じですが、ラージファイルの更新頻度や、対象ファイルの平均サ
イズ等は、どのような感じなのでしょうか？

リビジョン数とファイル数の接近具合から、「リビジョンあたり1つのファ
イルを変更」な印象がしないでもないですが（笑）

また、hg clone -U で単純に履歴情報のみを転送した場合の性能差はどう
なりますか？

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

[ohira]

おおひらです。

また、hg clone -U で単純に履歴情報のみを転送した場合の性能差はどう 

なりますか？ 

 ラージファイル化したリポジトリは半分の時間でクローンできました。

[shin@faith] ~/tmp% rm -rf sps2.5-trunkDEV* 

 [shin@faith] ~/tmp% time hg clone -U ssh://hg@escm/sps2.5-trunkDEV.auto ; time hg clone -U ssh://hg@escm/sps2.5-trunkDEV

destination directory: sps2.5-trunkDEV.auto

requesting all changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 51450 changes to 51447 files                            

29.202u 13.111s 1:23.11 50.9%   21+169k 252+103315io 206pf+0w

destination directory: sps2.5-trunkDEV

requesting all changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 51450 changes to 51447 files                            

60.692u 20.659s 2:09.73 62.6%   30+169k 67+107408io 0pf+0w

  - リビジョン数: 51450 

  - ファイル数:   51447 (ラージファイル扱いが 42259 ≒ 82%) 

という感じですが、ラージファイルの更新頻度や、対象ファイルの平均サ 

イズ等は、どのような感じなのでしょうか？ 

リビジョン数とファイル数の接近具合から、「リビジョンあたり1つのファ 

イルを変更」な印象がしないでもないですが（笑） 

 テスト目的で生成したリポジトリなので、実運用の履歴が入っているものでは

ありません。ラージファイル扱いのファイルとそれ意外のファイルの割合は

実際のものとほぼ同じです(拡張子で指定しているだけなので)

テストに使用したリポジトリはリビジョンが2つしかありません。

どのぐらい時間がかかったかの参考にはならないかもしれませんが

一応記録にとどめておこうとおもいました。

実際に運用しているsvnリポジトリでは、ラージファイル扱いを希望する

拡張子のファイルはほとんど更新しません。それなのに割合が多いので

チェックアウトの時間がかかるためsvnリポジトリを2つに分けて使用しています。

その2つを合成したものが今回テストで使ったhgリポジトリです。

2015年2月26日木曜日 21時06分44秒 UTC+9 FUJIWARA Katsunori:

[Katsunori Fujiwara]

藤原です。

2015年2月27日 18:30 ohira <shin....@gmail.com>:

>>>
>>> また、hg clone -U で単純に履歴情報のみを転送した場合の性能差はどう
>>>
>>> なりますか？
>>
>>
> ラージファイル化したリポジトリは半分の時間でクローンできました。

(snip)

> テスト目的で生成したリポジトリなので、実運用の履歴が入っているものでは
> ありません。ラージファイル扱いのファイルとそれ意外のファイルの割合は
> 実際のものとほぼ同じです(拡張子で指定しているだけなので)
> テストに使用したリポジトリはリビジョンが2つしかありません。
> どのぐらい時間がかかったかの参考にはならないかもしれませんが
> 一応記録にとどめておこうとおもいました。

参考情報だろうなぁ、とは思いましたが、実施条件が明示されないと、
「ラージファイルを使うと約3倍の時間」が一人歩きしてしまうので、念
のため言及させてもらいました（笑）

> 実際に運用しているsvnリポジトリでは、ラージファイル扱いを希望する
> 拡張子のファイルはほとんど更新しません。それなのに割合が多いので
> チェックアウトの時間がかかるためsvnリポジトリを2つに分けて使用しています。
> その2つを合成したものが今回テストで使ったhgリポジトリです。

これまでにも言及したように、ラージファイル扱いファイルの更新頻度が
低い場合、少なくとも「履歴情報の転送性能 (＋作業領域更新含む)」と
いう点では、largefiles 利用のメリットは高くないかと。


もしかしたら、以下の様な通信時圧縮の設定を見直したほうが良いかもし
れません。

- Mercurial の連携プロトコルレベルでの圧縮の有無

通信帯域幅の広い環境 (高速 LAN) で、且つ CPU 消費を減らしたい
場合向けに、hg clone --uncompress が利用可能です。(push/pull
では uncompress 指定ができません)

転送する履歴データの圧縮を抑止することで、転送量は増えますが、
CPU 消費や、圧縮・展開に要する時間を短縮できるため、トータルの
所要時間を短縮できるかもしれません。

※ サーバ側の [server] セクション設定で以下の制御が可能:

- uncompressed
False だと --uncompress 指定は無視される (デフォルト値は True)
- preferuncompressed
True だと極力 --uncompress 動作になる (デフォルト値は False)

http://mercurial-users.jp/manual/hgrc.5.html#server


- SSH レベルでの圧縮の有無

OpenSSH 系の実装では、通信経路における圧縮はデフォルトで無効に
なっています。

以下の様なケースであれば、多少余計に CPU を消費しても、データ
圧縮で通信量を低減させた方が、トータルの所要時間は低減できるか
もしれません。

- WAN 経由でのアクセスのように、通信帯域が広くない
(＝ 処理時間の大部分が転送待ちで占められる)

- 通信量に対して、CPU の余裕が大きい
(＝ 転送待ちするよりも、CPU をぶん回して圧縮した方が早い)

既に圧縮が掛かっている画像ファイルなどを含む履歴を転送する場合
は、あまり効果がないかも……

"[ui] ssh = ssh -C" や、~/.ssh/config 等で指定してください。


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