Fossil を個人的な Wiki ＋プロジェクト管理ツールとして使う - ヤルキデナイズドだった
Fossil というモノがあります。 SCM です。バージョン管理システムです。Subversion とか Git とか Mercurial みたいなヤツです。 聞いたことネーヨという人も SQLite くらいは知ってるかと思います。その作者 Richard Hipp が作ったソフトウェアと言われればピンとくるかもしれません。こないかもしれません。 ピンとこない方のために特徴を挙げますと： すべて C で書かれています。 単独の実行ファイルで動作します。 リポジトリは単一の SQLite データベースファイルに格納されます。 zlib 以外のライブラリに依存しません。 diff ツールも web インターフェースも内蔵しています（実例は Fossil の公式サイト）。 CGI としても単独のサーバとしても動きます。 Wiki も内蔵。 バグトラッキングシステムも内蔵。 もう一度書きますが全
Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd - プログラマの思索
Redmine・HudsonとSCMの機能の関連表 をチケット管理システムWikiに追加した。 【元ネタ】 チケット管理システムWiki RedmineとSCMの機能の関連表～BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索 特集：Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社 CIツールHudsonを使いこなす: プログラマの思索 言いたかったことは、RedmineがSCM(構成管理)と密接に関係するだけでなく、ビルド管理ツールHudsonの機能とも対応していることだ。 つまり、下記の機能がそれぞれ対応する。 【1】SCMコードライン⇔Redmineプロジェクト⇔Hudsonジョブ バージョン管理(Subversion、CVS、Git etc.)のリポジトリにあるtrunkやbranch単位で、ビルドモジュール(コンポーネント)が
RedmineとSCMの機能の関連表～BTSとSW構成管理の密接な関係 #itsjp #tidd - プログラマの思索
チケット管理システム比較WikiへRedmineとSCMの機能の関連表を追記した。 BTSとSCMに関する考えをラフなメモ書き。 【元ネタ】 チケット管理システム比較Wiki 構成管理とは何なのか - watawata日記 SW構成管理とはそもそも何なのか？: プログラマの思索 17-B-3 チケット駆動開発 タスクマネジメントからAgile開発へ - miyohideの日記 Agile開発とチケット駆動開発の大きな違いは、チケット集計機能だけでなく、構成管理ツールとの連携にあると思う。 「No Ticket, No Commit!」を運用して、BTSチケットに構成管理情報を紐づけると、単にチケットとSCMリビジョンが紐づくだけでなく、ビルドモジュールとBTSチケット、SCMコードラインとBTSプロジェクト、SCMタグとBTSのリリース予定バージョンが対応づけられる利点がある。 つまり、チ
A successful Git branching model - プログラマの思索
Gitの使い方について良い記事があったのでメモ。 【元ネタ】 見えないチカラ: A successful Git branching model を翻訳しました 少人数開発に役立つ5つのまとめ 構成管理について良い本は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」と「入門Git」の2冊。 これらの本を読んで理解した立場から書いてみる。 GitやMercurialのような分散バージョン管理では、ブランチをたくさん作るのが普通。 ブランチの目的を意識して、ブランチを管理するのが重要。 上記の記事では、メインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類が紹介されている。 僕の理解では、記事に書かれているメインブランチはtrunk、フィーチャーブランチはトピックブランチ、リリースブランチはまさ
プロジェクトで Git を使ってみた感想とか - miauのブログ
2009/12〜2010/06 くらいまでの案件で Git を使ってみたので、その感想その他です。毎度長くてごめんなさい。 Subversion の経験はそこそこある状態でのスタートです。 リポジトリ構成のポイント ソースコードは Git、ドキュメントは Subversion で Git はファイル名をバイト列で管理するので、Windows と Linux の両方で使いたい場合は日本語名のファイルは使えません。（今のところ対応予定もないとのこと。ファイルのコンテンツやコミットログについては UTF-8 で統一できるので問題ありません。） ソースコードについては日本語名のファイルは含まれないので Git 管理でいいと思いますが、ドキュメントに関しては難しいので Subversion 管理にしました。 リポジトリの単位は細かく Git では Subversion と違ってリポジトリの一部をチェ
私が、分散バージョン管理を使おうと思ったただ一つの理由
最近デビューしました。 たった一つの理由を挙げろといわれれば 今のプログラミング開発手法のマッチしているから に尽きる。 TDDやCIが良い例だと思う。 TDDの例 SVNの場合TDDのレッド⇒グリーン⇒リファクタリングのタイミングでコミットするには粒度が小さすぎる。 でもコミットしないと小さな不安が残る。だけど、コミットすると余計なリビジョンがかさむことになる。 分散バージョン管理であれば、レッド→グリーンになったタイミングでローカルブランチにコミット出来る。 そのあと、一つのTDD(設計工程)が終わった段階でまとめてメインブランチにpushする。 ※bazaarでのやり方がわからないんだけど（汗 自分で試行錯誤しているときは安心(グリーン)したタイミングでコミット。 で、ひと段落したらメインリポジトリへpushというのが自然な流れで実行できる。 CIの例 CIの場合に、SVNでよくやる
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
Mercurial基礎最速マスター -初期設定・基本編- - Akinekoの日記
タイトルはついったー上でみんながこれつけろって言われたので…ｗ というわけで最速マスターとなるかどうかはわかりませんが入門Mercurial Linux/Windows対応の復習も兼ねてまとめようと思います。 ちなみにインストール方法ではGUIツールのインストール方法も紹介しますが、GUIによる操作の説明はなくコマンドに関してのみの記事となっております。また、主に参考にしている本にはMacに関する記載がなく、僕もMac環境がありませんのでMacに関する説明は少なめとなっておりますこともご了承下さい。 追記： 2010/03/11 FreeBSDでのインストールについて(ついったーにてご指摘頂きました) 基礎文法最速マスターから基礎最速マスターへｗ 2010/03/11 マージツールの設定にTortoiseHgの場合を追加(コメントより) branchの説明を修正(コメントより) 2010/
コミットについて語ってみる - wyukawa's diary
途中から難しくなってきてとばし読み気味になったが実用Gitはすばらしい本だ。 入門Gitもすばらしかったがそれにも劣らない（この２冊ほどでは無いかもしれないが入門gitもいい本だ）。 読んでいて感じたのはGitは歴史を書き換えてでもいいコミットを作ることに関心を持っているように思う。 間違えたコミットコメントを修正したいと思うことは誰でもありそうだが、それだけではなくコミットをまとめたり、順番を変えたりすることもGitではできる。さながら歴史をリアルタイムで作り替えているようだ。 そうやって作られたある意味では完璧なコミット履歴を見てみたい気もする。 コミットについて語る場合２つのパースペクティブがある。１つは粒度でもう１つはコメントだ。 コミットの粒度は論理的にまとまった単位であるべきだ。例えば１つのバグ修正で３ファイルいじったなら１コミットであるべきでファイル毎に３回コミットされたら後
分散バージョン管理入門 (イラスト入り) - tcha.org
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
Re:mercurialでチケット駆動開発 - monjudoh’s diary
元記事 mercurialでチケット駆動開発 - logiqboard default・confirm・topic*いっぱいというbranchの使い方の懸念点 リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえるということで気になったのは、あるtopic branchでの変更について、 confirm branchにmergeして動作を確認しても、 そのtopic branchをdefault branchにmergeして正しく動作する事を保証しない、 ということ。 例えば開発完了したtopic branchがb1〜b5の5個あったとして、 b2,b4のみリリース予定は他より後になっているとする。 この時、confirm branchにb1,b2…という順番でmergeされているとして、 b5の正常動作がb2や
mercurialでチケット駆動開発 - logiqboard
本格的にmercurialを使い始めて数ヶ月、色々ノウハウがたまったのでまとめてみる。 想定する状況 VCSはmercurial一本で運用 IssueがなにかしらのBTSで管理されており、チケット単位でかつ並列に開発を進めたい リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえる リポジトリ配置 中央(central) どこかの共有サーバー上にあり、全ての開発成果が集まる場所。 中央@個人用(default) ↑と同じ場所にある個人の開発用の中央リポジトリ。個人ローカルと完全に同期する。 確認環境(test) 中央からclone, pullされる。リリースチェック、各チケットの動作確認を行う。 個人ローカル 個人の開発環境上に置かれるリポジトリ。やりたい放題する。 ブランチ運用 default リリースブランチ
Mercurialによるチケット駆動開発は強力だ！ - プログラマの思索
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】 →t
分散バージョン管理Git/Mercurial/Bazaar徹底比較
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
