Ports Collectionのディレクトリー(/usr/ports)のアップデートについて
Ports Collectionのディレクトリーのアップデートについて、昨日は、アップデートとしてカウントしていないと記事を書きましたが、本日確認した所、2015年2月19日から2016年6月1日の長期間に渡った分のアップデートについて確認した所、以下のように、/usr/portsが' U'として、つまりUPDATE3というか、中身は変わらないが、属性が変更になったアップデートとしてカウントされておりました。※注意してご覧ください。右上のターミナルは、viエディターにより、2016年6月1日のPorts Collectionのアップデートログファイルの末尾近くを見せております。最終行のREVISIONの一つ上の行をご覧ください。/usr/portsがUPDATE3' U'となっていることをご確認いただけます。
また、その日付以外のアップデートでは、/usr/portsはおろか、どのファイルにも属性のみの変更つまりUPDATE3が見つかりませんでした。一般的な日付のアップデートとして、右上のターミナルに表示させた2016年12月12日から12月26日までの間のアップデートの例で、最終行のREVISIONの一つ上の行に/usr/portsがアップデートされている形跡がないことと、左下のターミナルに表示させた結果が、2016年6月1日以外は、UPDATE3が０、つまり全くカウントされていないことで判断できたことをお確かめください。
今の所、何故今年6月1日のアップデートでディレクトリーがUPDATE3のアップデートとしてカウントされて、その他の日付では、カウントされないのか理由が分かっておりません。長期間に渡ったことで、属性が変化する要因があったものと思われますが、具体的に何がどう変更されたのか不明です。ご存知の方がいらっしゃいましたらお教えください。
通常のFreeBSDからのソースファイル入手におけるアップデート
subversionによるアップデートの種類は、先日お伝えした通りですが、FreeBSDなどで通常ソースファイルを入手した場合。
FreeBSDなどの各ブランチなどのコミッター間や責任者間で、例えば、CONFLICTやMERGEやEXIST、REPLACE、BROKENなどが発生した物は既に、除外されて、公に問題なしという物だけでファイルが構成されていることを、ある程度保証しているものと思われます。
よって、現状、私の使わせてもらっている自作のツールで、ほぼ間違いなくアップデートは拾えるものと考えています。
一応、今までにアップデートを入手した範囲のアウトプットから、有り得る全てのパターン記号を数え上げるプログラムを自作して実行して見ました。プログラムと結果の一部をお見せします。
以上のように、現在のところ、UPDATED、ADDED、DELETED以外の文字は調査範囲内では見当たりませんでした。
今日のsubversionアップデート
今日行った、subversionによるPorts Collectionとソースファイルのアップデートは以上です。
ちなみに、UPDATE1は、中身が変更され、属性は変わらないアップデート
UPDATE2は、中身も属性も変更されたアップデート
UPDATE3は、中身は変わらないが、属性が変更されたアップデートです。
今までは、ソースファイル全体を収めているディレクトリのアップデートをアップデートとしてカウントしておりませんでしたが、これからは、それもsubversionの伝える通り、中身は変わらないが属性の変更になったアップデートとして、つまりUPDATE3としてカウントしております。
Ports Collectionの場合も、Ports Collectionを収めている/usr/portsディレクトリについて、UPDATE3として、つまり中身は変わらないが属性は変更になったアップデートとして数えられている場合があることを確認しました。これは、2015年2月19日から2016年6月1日に渡る長期間に認められました。(12月27日確認12月26日分記事を編集)
しかし、その他の日付でのアップデートにおいては、/usr/portsのディレクトリーのアップデートは確認出来ませんでした。(12月27日分記事をご参照ください)
その差異がどのような要因によるのかは、今の所分かっておりません。(12月27日現在)
さて、今日のPorts Collectionのアップデートは、
#svn update /usr/ports
UPDATE1: 2324
UPDATE2: 26
UPDATE3: 0
ADD: 675
DELETE: 175
REVISION: 429476
LAST CHANGED REVISION: 429476
ソースファイルのアップデートは、
#svn update /usr/src
UPDATE1: 240
UPDATE2: 0
UPDATE3: 1 (このカウントされたUPDATEはソースファイル全体を収めているディレクトリのアップデートが数えられています。)
ADD: 20
DELETE: 0
REVISION: 310560
LAST CHANGED REVISION: 310558
subversionのアップデートを数えるプログラムを改定しました。(count14.rb)
subversionのアップデート情報には、次のような種類があります。(これが全てかはまだ調査中です)
U 属性は変わらないが中身が変更されたもの
UU 属性も中身も変更されたもの
U 属性のみの変更で、中身は変わらないもの
A 追加されたもの
D 削除されたもの
C コンフリクト(矛盾)したもの
G マージされたもの
E 存在しているもの
R 置き換わったもの
また、３番目のコラム(column)にBが来たものはBroken(壊れている)、また３番目のコラムにCが来たものは、コンフリクトしているという%svn help updateの説明もあり、実際どんなパターンが有り得るのかは、まだ捉えきれておりません。
当座、これで間に合いそうなものとして、以下のように(プログラムの一部です)、count14.rbを作成しました。(完璧ではないのですが、ご了承ください)
#ruby count14.rb 出力ログファイルのリスト
(suで実行する必要はありませんが)でアップデートを数えさせた結果はこんな感じです。
このsubversionのアップデートを数えるプログラム(count11.rb→count12.rb)は正しいでしょうか？
subversionのアップデートを先頭文字だけで数えるプログラムで計算していましたが、過去の分まで重複してアップデートされているものも数えるプログラムに修正したつもりです。自分では何か怪しげな感もあり、テストでは考えているように動いていそうですが、よく分かりません。（2016-12-12時点）
このプログラムの欠陥をお見抜けになるでしょうか？
もっとスマートなプログラムにする方法はいくらでもありそうな気がします(^^;
追記2016-12-13：単純なミスが見つかりました。先頭文字が空白(スペース)文字の時があるので、それに対処する必要がありました。
修正版はこれです。難しいプログラムではないので柔軟性はありませんが、現状問題無さそうに見えます。
