Mercurial 勉強中 (6) - named branch と update -C - daily dayflower
今回は named branch についてです。別に Mercurial を利用するうえで必須の概念ではないのですが，こいつを使うと multiple heads での changeset 間移動に習熟できますので。 ひとことまとめ Multiple heads は怖くない！hg update -C で branch 間の移動も自由自在 ただし，update するまえに commit しといてね 準備 まず作業用のレポジトリを作ります。 % hg init % touch 1 2 % hg ci -A -m "1, 2 added" adding 1 adding 21 と 2 というファイルも追加しました。commit のオプション -A とは，commit 時に同時に addremove をかけてくれる……すなわち，未 commit のファイルを自動的に追加削除してくれる，というお役立
Mercurial MQ について - daily dayflower
巷では git の大ブームだけど，ひさしぶりに Mercurial について書きます。 Mercurial について言及されたブログとか読んでいるとき，たまに MQ という言葉を目にして気になっていた。ながらく気にはとめつつ全然調べていなかったんだけど，ちょっと利用しようかなというケースがあり，ちょこっと触ってみた。 自分の理解では，MQ (Mercurial Queues) とは，誤解を恐れずにいえば Mercurial の changeset と独立して構成される修正履歴（パッチ）のスタックのようなものだ。 （なので今後 MQ の patch queues を Queues という名称と裏腹に「パッチスタック」「パッチ群」などと勝手に呼び称します） 「誤解を恐れずにいえば」と書いたけれど，この直感的な印象は MQ を使っていくうちに――大筋では変わらないものの――ちょっと変わった。それ
Mercurial 勉強中 (4) - branch と heads - daily dayflower
Mercurial には branch という概念があります。これは Subversion で svn cp にて能動的に利用する branch とは違って，システムで用意されている機能です。なので，Subversion における branch(es) のことはスッパリ忘れてください。 ややこしいのは，Mercurial には branch をサポートするためにいくつかの機構があり，それを同じ「branch」という用語で呼んでいることです。ざっくり書くと下記の 3 種類があります（⇒What are branches, merges, heads, and the tip? - FAQ - Mercurial, Branch - Mercurial）。 複数レポジトリによる概念的な branch unnamed branch（別 changeset を元として派生することで生ずる） nam
Mercurial 勉強中 (3) - .hgignore で無視リスト - daily dayflower
要旨 SCM にはバージョン管理の対象外としたいファイルを指定するのに「無視リスト」という機能があります。 Subversion では svn:ignore プロパティにより無視リストを指定する このため，cp や mv 時に無視リストも引き継がれる また，あくまで svn:ignore プロパティの設定されたディレクトリ直下のパスが対象となる Mercurial では Working directory 直下の .hgignore ファイルにより無視リストを指定する 指定方法は glob（シェルのワイルドカード風）と regexp（正規表現）の 2 通りがある 混在可 用途により使い分けるとよい *.tmp 等，ある拡張子のファイルをすべて無視するのなら glob ダイレクトな指定や複雑な指定なら regexp Subversion における無視リスト Subversion の場合，ディ
Plan 9
目次 0.0.1 注意事項 1.0.0 ニュース 2.0.0 Plan 9 とは 2.1.0 誕生 2.2.0 現在のコミュニティ 2.3.0 ホームページの目的 3.0.0 目次 3.1.0 Plan 9 のインストールと運用 3.2.0 Plan 9 の香り 3.3.0 プログラミング 3.4.0 UNIX との違い 3.5.0 Pegasus プロジェクト 3.6.0 その他 4.0.0 Plan 9 第四版 マニュアル 5.0.0 Plan 9 関係へのリンク 5.1.0 海外(団体) 5.2.0 海外(個人) 5.3.0 国内(俺のもあるよと言う人は知らせて下さい) 5.4.0 Web 上の記事 5.5.0 News Group 改訂: 2008/01/07 Plan 9 とは 誕生 Plan 9 は1995 年に Bell 研究所によってリリースされた新しいオペレーティングシ
[Think IT] 第4回：チケットとソースコードを連携せよ！ (1/3)
【バグ管理の作法】Trac徹底活用！ 第4回：チケットとソースコードを連携せよ！ 著者：masuidrive 公開日：2007/12/27（木） Tracの最大の利点はSubversionとの連携にあり さて、最終回の今回はTracのチケットとソースコードの連携を実際に試していく。 コードを書く開発者から見た場合、Tracの最大の利点は普段使い慣れたSubversionから、Tracを使うことができる点にある。開発者は自分の環境に新たなツールをインストールすることなく、Tracへ情報を送ることができる。 Tracの操作は通常Webから行うが、すべての操作をコマンドラインからでもできる。この機能とSubversionへコミット時に自動的にコマンドを呼び出すフックという機能を組み合わせることで、開発者がリポジトリへコミットするとTracを操作するという処理を自動化できるのである。 Subver
livedoor Developers Blog:チケット駆動開発の研究と実践 - livedoor Blog（ブログ）
こんにちは、そろそろ花粉のシーズンが近づいてきて戦々恐々としている金子です。 今年も花粉対策グッズの CM に注目しているのですが、花粉鼻でブロックがいいんじゃないか?と思っています。 花粉症のくしゃみ鼻水は、本人が辛いのはもちろんですが周囲にとっても気分の良いものではありませんよね。エチケットとしても花粉対策は怠らないようにしたいものです。 チケットついでに今回はチケット駆動開発の話をします。想定読者は Trac をリポジトリブラウザとして利用しているがチケットは使ったことがない人です。Trac、 Issue Tracking System という用語に馴染みのない方は、それぞれ関連リンクを用意しましたのでそちらをご覧ください。 以下、僕の経験に基づき「チケット駆動開発とは何か」「何が目的か」「どう実践したか」「結果が出たか」についてレポートします。だいたいここ二週間くらい、チームではな
オープンソースソフトウェアのからくりとしくみ - sanonosa システム管理コラム集
先日本屋の中でぶらぶらしていたら、なかなか良い本を見つけたのでご紹介してみます。オープンソースソフトウェアがどのように作られていて、またどのように作れば良いか具体的に説明されていて結構面白かったです。オープンソースってプログラミング力以前にどういうルールで作ればいいのかという段階でつまずくことがありますが、この本があればそのレベルは軽くクリアできます。 こういう実践的な情報はWEB上でもなかなか見つからないので貴重です。内容が結構良いのに無名（だと思う）なのはもったいないです。 以下引用。 「システム管理者もオープンソース開発者も必読の1冊! OSSのブラックボックスを丸ごと解説!! 本書は、Linuxが「どのように構成されているのか」「その構成要素はどのよう にして作られているのか」についてを平易に解説、UNIX系OSを裏側から支える 数々の仕組みを理解できます。Linuxを日常的に利用
「簡単ですよね」という挑発 | おごちゃんの雑文
SIに限らず、「技術的な客商売」をやっていると、時として打合せの時に「簡単ですよね」という「挑発」を受けることがある。 それが実際に簡単であるかどうか、また相手が本当に挑発しているのかは別にしてこれは一つの「挑発」だと受け取った方がいい。なぜなら、あいての意図はどうであれ、そこにはいわゆる「罠」があるからだ。 多くの時「簡単ですよね」と言われたことは、実は技術的にはそんなに難しいものではないことが多い。また実際に難しくても、その現場にはもっと難しい問題が転がっていたりする。また、このような発言がされるタイミングは、議論なり整理なりがある程度進んでいて、顧客が先行きにある程度の見通しが立った時でもある。だから、結局のところそんなに難しいものではない。「簡単ですよね」と言われたものの多くは、実際に簡単だ。 ではそこで「はい」と答えたらどうなるか？ 多くの客はその「はい」は受諾の「はい」とみなす
Emacsからgitのブランチを扱うgit-dwim.elをリリース - http://rubikitch.com/に移転しました
【Emacs本を書きました】 gitはブランチが強力です。 ブランチは単なるポインタなので、gitではブランチの積極的な利用が推奨されています。 トピックブランチ特に「トピックブランチ」は便利なブランチ利用法です。 作業前に特定の作業用のブランチを切り、無事に実装できたらmasterにマージ（リベース）し、ブランチを削除する方法です。 トピックブランチを切ることで、現在の目標を明確にすることができます。 また、緊急の修正をする場合はあわてずに一旦masterに戻って修正し、再びトピックブランチで作業することができます。 トピックブランチについては http://progit.org/book/ja/ch3-4.html が詳しいです。 トピックブランチを作成するnewtopicとういう名前のトピックブランチを作成するには、以下のコマンドを使います。 $ git checkout -b ne
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
先週の茶袋：イタリア・ローマ、そして水星人の運命 — Community Engine Plus
プラン9 - Wikipedia