DVCSのリンク集 - うさぎ組
共有したい個人メモということで。会社の人とかね。 雑感。DVCSの情報は、不正確なコピペ情報が反乱していて、Git, Hgあたりは結構ひどい。有用なやつはTipsとしてまとめたけど、なかには誤読すると大変なものもある。 「急がば回れ」的に基本から勉強するのが間違える可能性がかなり低くなる。 基本から体系的に学べるものは各DVCSのガイドにした。 ガイドにあがるようなものでも、15hくらいあればハンズオンしながらでもこなせるので、仕事中に困りながら1weekうまくいかないくらいなら、基本からやって、出来る範囲だけを仕事でやるほうがいい。 正直、DVCSなくても仕事できるし、出来る前提の職場なら、職場のワークフローを先輩に聞きながら1weekくらい作業すればいい。 SCM 概念とか DVCSについてだし、書きかけ。【5分でわかるDVCS！ + 20分でわかるGit入門 by Kyon Mm o
Bazzar の Push と Merge - at_yasu's blog
良いスレ(【bzr】Bazaarでバージョン管理 Rev 2)があって、pushとMergeの解りやすい説明があったからコピペ。 180 ：デフォルトの名無しさん：2010/05/12(水) 01:40:55 コミットログとpullの動作で質問 共有リポジトリにtrunkブランチをinitして、 そのtrunkを異なる３つのフォルダに落とす。 dir:work_T => trunkログ確認用。 dir:work_A => あるファイルを変更 dir:work_B => work_Aで触っていない別のファイルを変更 として、AとBをpushしたら、work_Aのコミットログが消えました。 すぐ試せるコマンド書くんで、自分がおかしいのかbazaarがおかしいのか（仕様）なのか 教えてください。 （改行多いので次のカキコ） 181 ：デフォルトの名無しさん：2010/05/12(水) 01:45
本当は怖い軽量チェックアウトの話 - methaneのブログ
前回は、作業ツリー上でコミットすると、別の場所にあるブランチに新しいリビジョンが追加されるチェックアウトについて説明しました。 今回はチェックアウトの別の仕組みである軽量チェックアウト (lightweight checkout) について説明します。 軽量チェックアウトの使い方 軽量チェックアウトを使う方法は、通常のチェックアウトをするときに --lightweight というオプションを付けるだけです。 $ # /path/to/branch にあるブランチの軽量チェックアウトを workingtree に作成する $ bzr checkout --lightweight /path/to/branch workingtree軽量チェックアウトを使うときは、チェックアウト元のブランチは同じマシン上のものにしてください。 その理由と、軽量チェックアウトのメリットをこれから説明していきます
[bzr] チェックアウトとブランチの使い分け - methaneのブログ
bzr が git や hg と大きく異なるのは、メインラインの概念とチェックアウト機能だと思います。 メインラインについては昨日の Advent Calnedar で wonderful_panda さんが解説してくれました。(ブランチのメインラインのイメージについてしゃらくさい話をするよ - wonderful_pandaの日記) 今日はチェックアウト機能について紹介し、通常のブランチとの使い分けを解説します。 チェックアウトとは チェックアウトとは作業ツリー、あるいは作業ツリーを作成するコマンドのことです。作業ツリーは常にどこかのブランチに紐づいています。 bzr のチェックアウトは、紐づくブランチが別の場所（別のディレクトリや別のサーバー上）にあってもいいところがユニークです。 $ bzr checkout lp:bzr-colo colo-co # colo-co は lp:bz
![[bzr] チェックアウトとブランチの使い分け - methaneのブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/abaa7a98daddfe2bbbd616cb25ba54d9ed4c5f50/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704591929890341541%2F12704591929890341569%2F1348037582)
そういえば共有リポジトリについてちゃんと説明してナカタヨ - wonderful_pandaの日記
SCMBCとかでも説明せずにはしょったんですが、Bazaarには共有リポジトリという仕組みがあります。DVCSとして運用するためには、この仕組みを使うのと使わないのとで快適さがまるで違うので、そろそろちゃんと説明しておきます。 DVCSとして運用していると、以下のような理由などで、どんどん新しいブランチを作ることになると思います。 複数の新機能追加やバグフィックスを並行してしなければならない うまくいくかどうか分からないけどちょっと試してみたいことがある なので、いかに簡単にブランチを切ったり切り替えたりできるかが、開発のリズムを保つためにも重要になるんですが、普通の(共有リポジトリを使わない)ワークスペース構成にしていると、新しいブランチを作るときに既存のブランチを丸ごとコピーしなければならず、時間がかかってしまいます。(もちろん、データサイズもその分大きくなります) それを解消するため
フックを作ってみる。 - wonderful_pandaの日記
Bazaarの特徴として、プラグインによって柔軟に機能を拡張できることが上げられます。 「フック」は、ほとんどのVCSが持っている、さまざまな処理の中に独自のチェックや処理を挟み込める仕組みのことですが、Bazaarの場合は、フックもプラグインとして実装します。 どんなフックがある？ 以下のコマンドで、作ることができるフックの種類をリストアップすることができます。 bzr help hooksまた、以下のコマンドで、実際にシステムにインストールされているフックをリストアップすることができます。bzr hooks 実装してみる。 例えば、コミットメッセージに問題が無いかチェックをするためのフックを作ってみましょう。 Bazaarのプラグインディレクトリにtest_hookディレクトリを作成し、その中に __init__,pyというファイルを置きます。 このファイルに、フックの処理を実装します
本当は怖いローカルコミット - wonderful_pandaの日記
前にShibuya.TracとかOSCでBazaarについて話したときには、 Bazaarだったら、SVNみたいに集中型で運用しながら、必要に応じてローカルでコミットすることもできるよ みたいなことを言ったんですが、最近はちょっと、ローカルコミットってのは挙動にクセがあるから混乱の元だし、使わない方が良さそうだという結論に(僕の中では)なってます。ローカルでコミットしたい場合はちゃんとブランチ切ろうねってことで。 ということで、お詫びもかねて、ローカルコミットを使うとどうなるかというのをちょっとご紹介します。 Pending Merge まず、前提となる用語について。 Bazaarの作業コピーには、"Pending Merge"という状態があります。これは、ここの「ステップ２：分散型の導入」のあたりにある、「mergeを実行したけれど、まだcommitはしていないよ」という状態のことですね
TortoiseBazaarを軽快に使うためのちょっとしたTips - wonderful_pandaの日記
TortoiseBazaarに限らず、Tortoiseファミリーのソフトを使うと、どうしてもシステムのパフォーマンスに影響が出てしまうんですが、そういう影響を最小限にするためのちょっとしたTipsです。 ※あくまで現状の実装ベースの話なので、今後状況は変わるかも。 作業コピーを一箇所にまとめる TortoiseBazaarは、アイコンオーバーレイの対象となる作業コピー内のファイルの変更を監視しているのですが、システム内に複数の作業コピーがあると、それらの共通の親ディレクトリを監視対象にするようになっています。 例えば、以下のようなフォルダ構成になっていると、"C:\DEVELOP"が監視対象になり、Bazaarとは関係のないtortoisehgやtortoisesvn配下のファイルの更新も拾ってしまいます。 C:\DEVELOP\tortoisebzr\trunk Bazaarの作業コピー
Bazaarで分散バージョン管理（作業編その１）
Bazaarで分散バージョン管理（チェックアウト編）からの続き いよいよ実作業に入っていきます。 作業ツリーは前回チェックアウトしたものを使用していきます。 ●変更＆追加＆差分表示 まずは main.c にちょっと処理を追加し、Makefile も作成しました。 Makefile は初コミットした時と同じ手順で 追加 を行います。 この状態で main.c には ！アイコン、Makefileには ＋アイコンが表示されます。 右クリックメニューから 差分 を選択しましょう。 すると差分ビューが表示されます。 追加された Makefile の全文と、main.c の変更点の周辺のみが表示されています。 また、Makefile 内の日本語文字列が文字化けを起こしています。 そこで、下のエンコード設定を変更して日本語を表示できるようにしましょう。 この場合、日本語は Shift-JIS で書いてい
Bazaarで分散バージョン管理（チェックアウト編）
Bazaarで分散バージョン管理（共有リポジトリ作成編）からの続き 今度は前回作った共有リポジトリから作業ツリーを取り出しましょう。 ●チェックアウト 適当な空フォルダを用意します。 ここでは bzrworkspace2 というフォルダを用意しました。 まず、フォルダ内のなにもないところで右クリックし、 「Tortoise Bazaar」>「チェックアウト/ブランチ」を選択します。 表示されたウィンドウで「ブランチ元」に共有リポジトリへのパス（ "\turnk" を含む）を入力します。 また、「作業ツリーを作成するローカルディレクトリ」にはエクスプローラで開いていたフォルダのパス + "trunk" が表示されているはずです。 これは、「ブランチ元」のパスの末尾のフォルダ名を勝手に付け加えてくれる謎のおせっかい機能の仕業です。 余計なフォルダを作成したくなければパスを修正して構いません。
Bazaarで分散バージョン管理（共有リポジトリ作成編）
Bazaarで分散バージョン管理（作業ツリー作成編）からの続き 前回作成した作業ツリー(リポジトリ)をチームで共有できるように、 Subversion のような共有リポジトリを作成していきます。 ※ 本来はHTTPサーバ等の上に作成させたほうがいいと思いますが、 （やったことが無いので）ここではファイルサーバー等の上に作成していきます。 ●リポジトリ初期化 ファイルサーバーまたはDropbox等、チームで共有できる場所に空のフォルダを用意します。 ここでは bzrrepository というフォルダを用意しました。 まず、フォルダ内のなにもないところで右クリックし、「Tortoise Bazaar」>「初期化」を選択します。 表示されたウィンドウで「新規共有リポジトリを作成」をONし、 「リポジトリ内に作業ツリーを作成しない」をONして「OK」を押します。 すると、フォルダの直下に ".b
Bazaarで分散バージョン管理（作業ツリー作成編）
Bazaarで分散バージョン管理（設定編）からの続き Bazaarを使ってゼロから作業ツリー(リポジトリ)を作成していきます。 ●リポジトリ初期化 以下のような main.c と define.h ファイルを含む bzrworkspace フォルダをBazaarで管理できるようにしていきます。 まず、フォルダ内のなにもないところで右クリックし、「Tortoise Bazaar」>「初期化」を選択します。 表示されたウィンドウで「新たな単体ツリーを作成」がONになっていることを確認して「OK」を押します。 （「履歴中のすべてのリビジョンNoを保持する」は使ったことが無いのでよくわかりません） すると、フォルダの直下に ".bzr" という隠しフォルダが出現します。 これが作業ツリーのリポジトリの正体です。 隠しフォルダなのでエクスプローラの設定を変えないと見れません。 .bzr フォルダの中
Bazaarで分散バージョン管理（設定編）
Bazaarで分散バージョン管理（インストール編）からの続き インストールしたBazaarをマージやコミットができるように設定していきます。 設定作業 ●TortoiseSVNの設定 まずはTortoiseSVNの設定から。 エクスプローラの何もないところで右クリックメニューを表示し、 「TortoiseSVN」 > 「Settings」 をクリックします。 「General」のなかにある「Language」を日本語にして「OK」をクリックします。 日本語が選択肢にない場合は日本語言語パックのインストールに失敗しているので、 言語パックのインストールをやり直してください。 もう一度設定メニューを開くと、メニューが日本語化されています。 右クリックメニューをすっきりさせます。 この設定はお好みで 「コンテキストメニュー」の設定で、以下のようにチェックのON/OFFをします。 「オーバーレイハ
Bazaarで分散バージョン管理（インストール編）
バージョン管理システムBazaarのインストール・設定方法を記述していきます。 現段階ではTortoiseSVNを使ったことがある人を対象にしています。 Bazaarの公式サイト http://bazaar.canonical.com/en/ まず、BazaarはGit、Mercurialに比べて以下の点が特に優れています。 ・日本語に対応している (モノによってはエンコードエラーは発生する可能性あり) ・空のフォルダをコミットできる (Git、Mercurialはフォルダを管理対象として見ていない) 3つのうち一番動作が遅いらしいですが、Subversionから最もスムーズに移行できるのがBazaarだと思います。(※Gitは使ったことがありませんが) 少し古い記事ですが、比較はこちらの記事が参考になるかと。 分散バージョン管理Git/Mercurial/Bazaar徹底比較 http:
Bazaarでcommit --amend - wonderful_pandaの日記
Bazaar Advent Calendar用に書きかけてて、結局出番のなかった「プラグインを作ってみる」というネタがあって、仕上げてアップしようかと思っていたら、ちょうど@hikaruworldさんのブログに同じテーマのエントリが掲載されました。 僕が書こうと思っていたこともほぼ網羅されているので、プラグインの作り方について特に書くことはなくなったんですが、せっかくなので説明用のサンプルとして作ったプラグインをさらしておきます。 プラグインの機能 recommitコマンドを追加します。Gitのcommit --amendのように、直前のコミットをやりなおすコマンドです。 Purpose: Edit last commit information. Usage: bzr recommit [LOCATION] Options: -v, --verbose Display more info
bazaarのプラグインを作る(1)
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つはビルド
Bazaar入門セッション — Bazaarスタートアップガイド v0.0.1 documentation
基本用語のはなし¶ Bazaar をはじめ、バージョン管理ソフトでは、名詞と、 その名詞が指すものを作る操作の動詞が、同じ単語になっていることがよくあります。 先に用語をしっかり理解しておくと、あとは文脈で動詞か名詞かを判断できるはずなので、 混乱しないように丁寧に解説して行きます。 リビジョン¶ １回のコミットで保存される情報をまとめたものです。１回コミットするたびに、新しいリビジョンがひとつ作られます。 「チェンジセット」と呼ばれることもあります。また、「コミット」(名詞)をリビジョンの意味で使うこともあります。 リビジョンに含まれる情報は、こんなかんじです。 リビジョンのID どのファイルが、どのように変更されたか コミットしたユーザ コミットした日付 コミットメッセージ 親(ひとつ前)のリビジョン ブランチ¶ リビジョンを積み重ねることで、開発が進んでいきます。この、一連のリビジョ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://standing-shoebill.appspot.com/bzr-startup-guide/index.html