昨日に引き続き、bzr-coloの話です。 「colo:」というプレフィックスをつけることで、Colocatedワークスペース内のブランチにアクセスできるのは昨日書いたとおりです。 例えばどんなことが出来るのか、いろいろやってみます。 colo: を使った操作の例 リモートブランチとの連携 新しいリモートブランチをワークスペースに取り込む $ bzr branch url/to/another/remote/branch colo:origin/another-branch # --bindで、チェックアウトとしてワークスペースに取り込むこともできます。 $ bzr branch url/to/another/remote/branch colo:origin/another-branch --bindリモートから取り込んだブランチを最新化する(アップストリームでの変更を追いかける)$ b

前回の続きです。 hello_world.pyだと色々とやりづらいので、 plugins以下にhello_worldという形でモジュール化しておきます。 $ ls ~/.bazaar/plugins hello_world.py $ cd ~/.bazaar/plugins $ mkdir hello_world $ mv hello_world.py hello_world/__init__.py 2-4.helloコマンドに引数を与える bzr stなどにLOCATIONを指定できるように、 自分で作ったプラグインにもコマンドライン引数を設定する事が可能です。 というわけで、helloコマンドにユーザ名を指定して hello usernameという形に出力するようにプラグインを拡張してみます。 引数を指定したい場合はtakes_argsというプロパティをクラス内に定義して、 取得したい

bazaarのよいところの一つはpythonで簡単にプラグインを書ける事です。 知ってはいたんですが、作った事なかったのでHelloWorldしてみました。 1.基本的なルール 1-1.プラグインのインストール場所 bzrのプラグインは$HOME/.bazaar/plugins以下に配備すると自動でモジュールをロードしてくれます。 実際にどんなプラグインをインストールしているかは、 bzr plugins とコマンドを打つことで確認できます。 1-2.参考にする実装 bzrは起動時にビルドインコマンドを読み込みます(bzr infoとかです)。 そのコマンド自体はbzrlib/builtins.pyで定義されているのでプラグインを作成するときには参考にしましょう。 2.helloプラグインの実装 2-1.プラグインの作成 プラグイン自体をbzrに認識させる方法は3つありますが、1つはビルド

前回は、作業ツリー上でコミットすると、別の場所にあるブランチに新しいリビジョンが追加されるチェックアウトについて説明しました。 今回はチェックアウトの別の仕組みである軽量チェックアウト (lightweight checkout) について説明します。 軽量チェックアウトの使い方 軽量チェックアウトを使う方法は、通常のチェックアウトをするときに --lightweight というオプションを付けるだけです。 $ # /path/to/branch にあるブランチの軽量チェックアウトを workingtree に作成する $ bzr checkout --lightweight /path/to/branch workingtree軽量チェックアウトを使うときは、チェックアウト元のブランチは同じマシン上のものにしてください。 その理由と、軽量チェックアウトのメリットをこれから説明していきます

Windowsの場合、スタンドアロンexeとして動作するBazaarか、Python.exeスクリプトとして動作するBazaarかのどちらを選択できます。 手軽なのはスタンドアロンexeの方で、インストーラを実行するだけで基本的な機能と主要なプラグイン、GUIクライアントなど一通り使えるようになります。 それとくらべるとPythonスクリプト版の方は色々と面倒はありますが、別のプログラムからBazaarのPython APIを利用できたり、Apache上でBazaarのサーバをホストできるようになるなど、色々とメリットもあります。 ※Pythonスクリプト版のBazaarを動作させるための手順は、 WindowsでBazaarをビルドするためのメモ - wonderful_pandaの日記 にまとめてあります。 ただ、Pythonスクリプト版の場合、TortoiseBzrがそのままでは動作

Bazaarの場合、「メインライン」という概念があって、そこさえちゃんとしていればよしという感覚なので、フィーチャブランチなどの履歴を改変して整理するっていうのは、あまりする必要がありません。 とはいえ、それでも履歴の改変がしたい場合もあります。例えば、 はじめての相手にマージリクエストを出すときはかっこつけたいし、しょうもないミスは消しておきたい 思った以上に履歴が長くなってしまったので、もう少し分割して個々にレビューを受けたい みたいな。という訳で、今日は歴史改変ネタで行きたいと思います。 標準機能でがんばってみる 実は、Bazaarの標準機能だと、あまり履歴の改変に使えるコマンドがありません。 基本的には、以下の２つの組み合わせになります。 uncommitやpullコマンドでコミットを取り消す mergeコマンドで、必要なリビジョンをチェリーピッキングする uncommitで、最新

何をするコマンド？ 作業コピー上で行った変更を、一時的に退避するためのコマンドです。個々のファイル内の変更を、部分的に選択して退避することができます。 git stashやhg shelveの仲間ですね。 使い方 shelveを実行すると、以下のように変更箇所(ハンク)が順番に表示されます。 それぞれの変更に対して、退避するならy、作業ツリーに残すならNで応答していきます。 $ bzr shelve -m "foo機能の実装方針を検討するためのコード" []--- scripts/tbzrcommand.py 2011-07-23 22:56:53 +0000[] []+++ scripts/tbzrcommand.py 2011-12-07 10:30:09 +0000[] @@ -147,7 +147,7 @@ 'add' : ('tbzrcommands.cmd_add', 'cmd

bzr が git や hg と大きく異なるのは、メインラインの概念とチェックアウト機能だと思います。 メインラインについては昨日の Advent Calnedar で wonderful_panda さんが解説してくれました。(ブランチのメインラインのイメージについてしゃらくさい話をするよ - wonderful_pandaの日記) 今日はチェックアウト機能について紹介し、通常のブランチとの使い分けを解説します。 チェックアウトとは チェックアウトとは作業ツリー、あるいは作業ツリーを作成するコマンドのことです。作業ツリーは常にどこかのブランチに紐づいています。 bzr のチェックアウトは、紐づくブランチが別の場所（別のディレクトリや別のサーバー上）にあってもいいところがユニークです。 $ bzr checkout lp:bzr-colo colo-co # colo-co は lp:bz

Gitには、reflogというコマンドがあって、ブランチのHEADがどのように移動してきたかを確認することができます。rebaseに失敗したときとか、間違えてresetしすぎちゃったときとかに復元するのに、とても便利(だそう)です。 Bazaarにはそういうの無いの？と思ったら、bzr-tiplogプラグインというプラグインがありました。 (参考)bzr headsコマンド 間違えて消しちゃったり、上書きしちゃったリビジョンを探すための機能としては、bzr headsというコマンドがあります。このコマンドは、リポジトリ内を走査して、削除済みのものも含めた全てのHEADリビジョンをリストアップできるコマンドです。 上記のような失敗から復元するときには、まずこのheadsコマンドを使うのですが、これは「リポジトリを走査」なので、リポジトリサイズに応じた時間がかかります。 これに対してtiplo

Bazaarの特徴として、プラグインによって柔軟に機能を拡張できることが上げられます。 「フック」は、ほとんどのVCSが持っている、さまざまな処理の中に独自のチェックや処理を挟み込める仕組みのことですが、Bazaarの場合は、フックもプラグインとして実装します。 どんなフックがある？ 以下のコマンドで、作ることができるフックの種類をリストアップすることができます。 bzr help hooksまた、以下のコマンドで、実際にシステムにインストールされているフックをリストアップすることができます。bzr hooks 実装してみる。 例えば、コミットメッセージに問題が無いかチェックをするためのフックを作ってみましょう。 Bazaarのプラグインディレクトリにtest_hookディレクトリを作成し、その中に __init__,pyというファイルを置きます。 このファイルに、フックの処理を実装します

まあVSSもそんなに悪いツールではないです。少なくとも90年代当時としては。悪いのは未だにVSSから離れようとしない連中の方ですよもう勘弁してください。 うちの会社はプロジェクトごとにバージョン管理の仕方はばらばらなんですが、他所のプロジェクトの手伝いに行ったりすると、ごくたまにVSSを使わなければならないことになったりします。そういう時に、クライアントにBazaarを使って少しは楽をしようとしたときのメモです。 前提 VSSにも一応マルチチェックアウトの機能はありますが、それが有効になっていることはまず無いです。あえてVSSを使おうという人たちはたいてい「同じファイルを同時に触るのは危険」だと思い込んでるので。 作業フロー VSSワークスペースの構築 VSSのデータベースから、「最新のバージョンを取得」でソース一式を作業ディレクトリにダウンロードします。 その作業ディレクトリを、そのまま

GitやMercurialの場合は、ブランチ構成は.gitや.hgフォルダの中に隠蔽されていますが、Bazaarの場合は個々のブランチは物理的に別ディレクトリになっています。 それがBazaarの特色であり、メリットも多いのですが、やっぱりGitやMercurialみたいにひとつのディレクトリで完結する形で作業したいよ、という人のために、「bzr-coloプラグイン」というのがあります。 このbzr-coloの機能、近くBazaar本体に取り込まれることになってまして、それに伴ってコマンド体系や仕様が変わる可能性が高いので、今更感はあるんですが、使い方を説明します。 こっちも十分に便利ですし、本体に取り込まれた後もしばらくそっちは様子見フェイズになると思いますし。 ワークスペースを作る サーバ上のブランチをコピーして、ローカルにワークスペースを作ります。 $ bzr colo-fetch

BazaarのGUIツールセットとして、qbzrプラグインというのがあります。 TortoiseBazaarやBazaar Explorerからも使われている、Bazaar GUIのデファクトスタンダードと言ってもいいものなんですが、この中に入っている差分表示コマンド(qdiff)がやたら使いにくい。 使いにくいと思うポイント 複数のファイルがまとめて表示される 複数のファイルが変更された状態でqdiffを実行すると、ひとつのテキストにまとめて表示されます。 読み込みもその分遅くなるし、頭出しの機能が無いから見たいところを探すのに苦労します。 外部Diffツールの起動をファイルごとにできない 上の件にも関係しますが、複数ファイルが表示されているときに、特定のファイルを対象に外部Diffツールを起動することができません。 スクロールがずれる サイドバイサイド表示の時に、差分が大きいとスクロー

前にShibuya.TracとかOSCでBazaarについて話したときには、 Bazaarだったら、SVNみたいに集中型で運用しながら、必要に応じてローカルでコミットすることもできるよ みたいなことを言ったんですが、最近はちょっと、ローカルコミットってのは挙動にクセがあるから混乱の元だし、使わない方が良さそうだという結論に(僕の中では)なってます。ローカルでコミットしたい場合はちゃんとブランチ切ろうねってことで。 ということで、お詫びもかねて、ローカルコミットを使うとどうなるかというのをちょっとご紹介します。 Pending Merge まず、前提となる用語について。 Bazaarの作業コピーには、"Pending Merge"という状態があります。これは、ここの「ステップ２：分散型の導入」のあたりにある、「mergeを実行したけれど、まだcommitはしていないよ」という状態のことですね

7月30日 SCM Boot Camp in Tokyo(1次応募)(東京都) 7月30日 SCM Boot Camp in Tokyo(2次応募)(東京都) (写真：会場の独特な雰囲気を切り取った印象的な一枚。URLはこちら。) 近年のソフトウェア開発においてSCM※1の重要性が増していますが、SCMで重要になってくる 「DVCS※2の概念・思想・パターン」を学習する機会はなかなかありません。 今後のソフトウェア開発に活かせるよう、講演と演習を通して「DVCSの概念・思想・パターン」を 学んでもらいたいと思います。 プログラミング言語に依存しない演習にし、プログラマーに限らず、 デザイナーや管理者などVCSの使用経験がある方であれば気軽に参加できます。 -------------------------------------------------- ※1 SCMとは？ Softwar