タグ

mercurialと開発に関するp260-2001fpのブックマーク (5)

  • 2010/12/17分散バージョン管理勉強会

    募集頁:http://kokucheese.com/event/index/6329/ ハッシュタグ: #shibutra 2010年12月17日(金) (19:00-22:00 (開場18:45)) 開催場所 古石場文化センター 2階 第1,2研修室 (東京都江東区古石場2-13-2) 続きを読む

    2010/12/17分散バージョン管理勉強会
  • A successful Git branching model - プログラマの思索

    Gitの使い方について良い記事があったのでメモ。 【元ネタ】 見えないチカラ: A successful Git branching model を翻訳しました 少人数開発に役立つ5つのまとめ 構成管理について良いは、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」と「入門Git」の2冊。 これらのを読んで理解した立場から書いてみる。 GitやMercurialのような分散バージョン管理では、ブランチをたくさん作るのが普通。 ブランチの目的を意識して、ブランチを管理するのが重要。 上記の記事では、メインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類が紹介されている。 僕の理解では、記事に書かれているメインブランチはtrunk、フィーチャーブランチはトピックブランチ、リリースブランチはまさ

    A successful Git branching model - プログラマの思索
    p260-2001fp
    p260-2001fp 2010/12/06
    リポジトリのl構成、ブランチ管理について。『メインブランチは、全てのブランチの本流』『逆に駄目な構成管理は、trunkを次々に乗り換えていくパターン』
  • Mercurialで独立並行リリース管理 - プログラマの思索

    「Mercurialで独立並行リリース管理」という良い記事があったのでメモ。 【元ネタ】 Computing Memo of 2008/02/26 パッチを作った場合、そのパッチを取り込む方法はCVS・SVN・Mercurialで違いがある。 例えば、コードラインAのリビジョン修正2にコードライン3のリビジョン修正3を取り込む場合、下記のようになる。 cvs up -j 修正2 -j 修正3 svn merge -r r修正2:r修正3 (A側) hg transplant -s (A')修正3 (前略) むっちゃ簡単! 「どのパッチを取り込む」かを指定するので指定には 「修正3」 とか一個だけでなく何個でも書け,「修正x:修正y」のようにコロンで区切って範囲指定もできる。 そして,既に適用したパッチかどうかはチェンジセットIDで確実に判別してくれるから,リバースパッチなんていうアホな自体

    Mercurialで独立並行リリース管理 - プログラマの思索
  • 分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project

    Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら

    p260-2001fp
    p260-2001fp 2010/03/23
    Subversionでgitの使い方を再現しようと思ったら確かにつらくて困った。そもそも考え方が違うのだという事でlinus氏の酷い罵倒も納得。入門Git到着が待ち遠しい
  • mercurialでチケット駆動開発 - logiqboard

    格的にmercurialを使い始めて数ヶ月、色々ノウハウがたまったのでまとめてみる。 想定する状況 VCSはmercurial一で運用 IssueがなにかしらのBTSで管理されており、チケット単位でかつ並列に開発を進めたい リリース順≠開発完了順(チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえる リポジトリ配置 中央(central) どこかの共有サーバー上にあり、全ての開発成果が集まる場所。 中央@個人用(default) ↑と同じ場所にある個人の開発用の中央リポジトリ。個人ローカルと完全に同期する。 確認環境(test) 中央からclone, pullされる。リリースチェック、各チケットの動作確認を行う。 個人ローカル 個人の開発環境上に置かれるリポジトリ。やりたい放題する。 ブランチ運用 default リリースブランチ

    mercurialでチケット駆動開発 - logiqboard
    p260-2001fp
    p260-2001fp 2009/12/09
    『開発順≠確認順≠リリース順という嫌な状況にも苦もなく対応できる』がポイント。検証用confirmブランチとリリースブランチを分ける。但しconfirmからリリースにマージしない。BTSのステータスに「verified」を用意。他。
  • 1