Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

bzr reconfigure

タグ: Bazaar
bzr reconfigure directory

bzrディレクトリを任意のブランチ/ツリー/チェックアウト/リポジトリに再構成する。
bzr bindbzr unbindbzr checkout . はこれの機能限定簡略版。
これを使うと前回挙げたほとんどの構成を行き来できる。
また、(2.0.0時点では)再構成でしか作れないスタックチェックアウト(stacked checkout)なんてものもある。

$ ls -a                             # スタンドアロンツリー「hoge」が存在する
.       ..      hoge
$ bzr init-repo .                   # カレントディレクトリを共用リポジトリに
Shared repository with trees (format: 2a)
Location:
  shared repository: .
$ bzr info hoge                     # hogeは「スタンドアロンツリー」である 
Standalone tree (format: 2a)
Location:
  branch root: hoge
$ ls hoge/.bzr                      # スタンドアロンツリーの.bzrの中身
branch          branch-lock     checkout        readme          repository
branch-format
$ bzr reconfigure --use-shared hoge # 共用リポジトリを使うようhogeを再構成
$ bzr info hoge                     # hogeは「リポジトリツリー」になった
Repository tree (format: 2a)
Location:
  shared repository: .
  repository branch: hoge
$ ls hoge/.bzr                      # hoge/.bzr/repositoryがなくなった
branch          branch-format   branch-lock     checkout        readme
$ touch hoge/hoge.txt               # hogeの作業ツリーにhoge.txtを追加
$ bzr status hoge                   # 作業ツリーに未管理のファイルがある
unknown:
  hoge.txt
$ bzr reconfigure --branch hoge     # 作業ツリーを持たないようhogeを再構成
$ bzr info hoge                     # hogeは「リポジトリブランチ」になった
Repository branch (format: 2a)
Location:
  shared repository: .
  repository branch: hoge
$ ls hoge/.bzr                      # hoge/.bzr/checkoutがなくなった
branch          branch-format   branch-lock     readme
$ bzr status hoge                   # 作業ツリーがないのでstatusコマンドはエラーとなる
bzr: ERROR: No WorkingTree exists for "hoge/.bzr/checkout/".

bzr initやらinit-repoやら

タグ: Bazaar

普段Subversionばかり使っている自分がBazaar 2.0.0のリポジトリやらブランチやらツリーやらチェックアウトやらの関係を理解するためのまとめ。
随時更新。

bzr init-repo repos

reposディレクトリに.bzr管理ディレクトリ(control directory)を作成し、reposディレクトリ以下を共用リポジトリ(shared repository)にする。
共用リポジトリの.bzrにはrepositoryディレクトリが作成され、共用リポジトリに作られたブランチのリビジョンはそこに格納される。

bzr init-repo --no-trees repos

作業ツリー(working tree)を持たない共用リポジトリを作成する。
作業ツリーとは、.bzr以外の、ユーザが直接編集するいわゆる作業コピーのことを指す。

この共用リポジトリに作られるブランチにはデフォルトで--no-treeオプションが付く。
主に集中型リポジトリを作成する際に使う。

bzr init trunk

trunkディレクトリに.bzrディレクトリを作成し、trunkディレクトリをブランチ(branch)にする。
ブランチは作成される場所によって呼び名とリビジョンの格納先が変わる。

共用リポジトリに作られたブランチはリポジトリブランチ(repository branch)となる。
リポジトリブランチの.bzrにはrepositoryディレクトリは作成されず、リビジョンは共用リポジトリの.bzr/repositoryディレクトリに格納される。

共用リポジトリ以外の場所に作られたブランチはスタンドアロンブランチ(standalone branch)となる。
スタンドアロンブランチの.bzrにはrepositoryディレクトリが作成され、リビジョンはそこに格納される。

ブランチはまた作業ツリーの有無でも呼び名が変わる。
ブランチが作業ツリーを持つことを明確にしたい場合、「ブランチ」ではなく「ツリー」と呼ぶ。
すなわち「作業ツリーを持つスタンドアロンブランチ」はスタンドアロンツリー(standalone tree)であり、「作業ツリーを持つリポジトリブランチ」はリポジトリツリー(repository tree)である。

bzr branch parent_branch my_branch

parent_branchブランチのコピーとしてmy_branchブランチを作成する。
他の分散型SCMで言うところのclone。
bzrのcloneコマンドは、2.0.0現在branchコマンドの単なるエイリアスとなっている。

このコマンドで作られるブランチもinitコマンドで作られるもの同様、共用リポジトリに作られればリポジトリブランチに、それ以外の場所に作られればスタンドアロンブランチになる。
my_branchparent_branchと同じ共用リポジトリに作られた場合、両ブランチ間で共用可能なリビジョンは共用されるため、Subversionでブランチを切るのと同程度のコスト感覚でブランチを作成できる。

bzr branch --stacked parent_branch stacked_branch

parent_branchブランチの上に「積み重ねるリビジョンのみを格納」するスタックブランチ(stacked branch)を作成する。
その役割上、スタックブランチは必ず独自のリポジトリを持つ。
共用リポジトリに作ってもリポジトリブランチにはならず、スタックブランチ独自のリポジトリにparent_branchブランチのリビジョンがコピーされることもない。
そのため、parent_branchブランチにアクセスできない状況では、stacked_branchブランチではコミットはおろかdiffを取ることもできない。
これは「diffやrevert程度はリポジトリにアクセスしなくても行える」Subversionの作業コピーよりも厳しい制約である。
その上、Bazaar 2.0.0ではこのブランチにコミットしようとすると

bzr: ERROR: Cannot commit from a lightweight checkout to a stacked branch. See https://bugs.launchpad.net/bzr/+bug/375013 for details.

という実態に即さないエラーメッセージが出てコミットできない。

bzr branch --no-tree parent_branch no_tree_branch

parent_branchブランチのコピーとして、作業ツリーを持たないno_tree_branchブランチを作成する。

bzr checkout trunk working

workingtrunkブランチのチェックアウト(checkout)を作成する。
チェックアウトは「コミットしたリビジョンが即座にブランチに伝搬される」という点でSubversionの作業コピーのようなものと言える。
ただしSubversionとは違い「ブランチの一部をチェックアウト」したり「チェックアウトした一部分のみを bzr update 」することはできない。

チェックアウトはスタンドアロンブランチと同じように「全てのリビジョンをコピーする」ため、過去のリビジョンを参照する際にもブランチへのアクセスを必要としない。
それどころか bzr unbindチェックアウトをブランチにbzr bindブランチをチェックアウトにすることもできる。
ゆえにチェックアウトは束縛されたブランチ(bound branch)とも呼ばれている(と、思う)。

bzr checkout --lightweight trunk working

workingtrunkブランチの軽量チェックアウト(lightweight checkout)を作成する。
軽量チェックアウトは通常のチェックアウト(heavyweight checkout――lightweightとの対比から)にスタックブランチの特性(リビジョンをコピーしない)を合わせたようなもので、より一層Subversionの作業コピーに近い。
が、やはりこれもスタックブランチ同様、ブランチにアクセスできないとコミットすることもdiffを取ることもできない。
通常のチェックアウトは bzr unbindbzr commit --local でブランチから一時的に切り離してチェックアウト自身にリビジョンを作成できるが、軽量チェックアウトではそれも不可能。

bzr checkout branch

checkoutコマンドは引数が1つ以下の場合、指定したブランチに作業ツリーを生成する。
つまり「ブランチをツリーにする」。

bzr update working_tree

作業ツリーの内容をブランチの最新に合わせて更新する。

参考:

北欧神話の虹の名をTime Capsuleに付けて

Xbox 360の『Steins;Gate』をプレイ。
体験版を試しにプレイしたときは

「これはまた同調し難い主人公だな……」

と思ったが、よく考えてみれば

  • 神話の如く語られる「プログラム概要」
  • ギリシア神話(一部北欧神話)の固有名詞を付けられた「関数」
  • いかにもな名前を付けられた「システム」「変数」「ステート」

というそれは素敵なプログラム仕様書を書いたことのある自分がこのノリに付いて行けないわけはないのであった。

この作品を構成するネタは主に「SF」「ネットスラング」「厨二病」。
どれも好きなジャンルなので、その数々の小ネタは大いに楽しませてもらった。
「日本人の粉塵爆発好きは異常?」と頭の片隅で思いながらプレイしていているとやがて「小麦粉の袋が積まれた部屋」が出てくるという。そんな至れり尽くせり。
ただ、情報工学が絡む話は一部私には解釈し難く、しばしば( ゚д゚)ポカーンとなることもあった。

ネタを取っ払った本筋はというと、これは「コールスタックをポップしていく」ような話であると認識。
そんな認識をしたせいか、復帰処理に移る前にスタックメモリが解放されることを悔やむ主人公の気持ちにはあまり同調できず。
その辺を「そういう感慨もあるのだな」と流してしまえば、展開自体は好きな類のものが多く、面白かった。
登場キャラが男女ともに皆可愛いのも良し。

しかしまあ。ノベルゲームはだいぶ久しぶりにプレイしたわけだが、やはりこのジャンルは良い。
なんといってもAボタンを押しているだけで話が進んでクリアできるのが良い( ´∀`)
選択をミスっても、それはそれでCGや別エンディングを回収できるから良し。
繰り返しプレイを前提にシステムが組まれているから、時限性のイベント(アイテム)を逃してやる気をそがれることもない。
このような淡々とカバレッジを増やしていくゲームジャンルは、プログラムのテストに疲れた体を癒すのにもってこいだ。

……本質的にやってることはあまり変わらん気がするが('A`)

Time Capsule導入

いい加減、Time Machineを使うためにいちいちMacBookに外付けHDDを繋げたり、PSPとかのWi-Fi機器をインターネットに接続するためにインターネット共有を有効にしたりといった地味な作業をやめたくなったので、1TBのTime Capsule(MC343J/A)を買った。
ついでにUSB HDD(HDCN-U500A)を買ってREGZA Z3500に接続し、地味にファンの音が気になっていた録画用のNAS(LS-L500GL)を止めた。
うーん、静かでいいね( ´∀`)

本当はREGZAがTime Capsuleを認識したら録画用HDDの役割も担わせようかと思ったのだが、どうやっても認識しないので諦めた。Time Capsuleのログを見る限り、REGZAからGuestや任意のユーザでログインするところまではいけているようなのだが……
もっとも、認識しようとしまいと、障害耐性という点ではこの構成がベストではある。
正直、この「熱量の塊」に連続稼働性を期待する気にはあまりなれない。

まあ、熱量の塊といっても、普段使っている分には「温かい」程度。
Apple製品は「静かな代わりに熱い」印象があるので、このくらいの熱さはまあ普通。
さすがに熱で変色とかされたら、それは設計に疑問を抱くが……

熱で変色したFXG-08MK

↑は2年ほど使ったFXG-08MK。
特に熱を持つ部分だけ見事に色が変わって(変質して)いる。
動作上、問題はない。

Redmine 0.8.6

Redmine 0.8.6 Changelog
  • Change subversion adapter to not cache authentication and run non interactively

Subversion 1.6のパスワード保存確認プロンプトに引っかかる問題が修正されている。
ていうかこれ、trunkではもう7月に対応されていたのね……

Appendix

タグ

Blog内検索

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。