Source

redmine-shinagawa-20120519 / source / index.rst

Full commit

Redmine 2.0 リリース

テーマ

  • Ruby 1.9 対応
  • Rails 3 対応
  • ブランチ管理

Ruby 1.9対応

Ruby 1.9対応 - Rails2での現象

  • 現象
    • ChiliProject 2.4.0 (2011-10-31) 直前の チケット676チケット591
      • 日本語WindowsとLinuxの非utf-8ロケールで起動しない
      • 日本語の題名のチケットを作るとこける

Ruby 1.9対応 - Rails2対策その1

Ruby 1.9対応 - Rails2対策その2

  • Rails2対策は Rails3で必要無いので削除

Rails3対応

Rails3対応 前段

  • Note 1
    • Someone already did the job
  • Note 13 2011-06-20 Rails3.0
    • I merged trunk r6097

Rails3対応の(自分の)基本方針その1

  • 互換性のあるものをtrunkに入れる(バックポート)

Rails3対応の(自分の)基本方針その2

  • (git/hgの)mergeではなく rebase
    • コミット単位を小さくする
    • リビジョンを 直線 にする
    • Rails 3.0 -> 3.1 -> 3.2 と順番にする
      • それぞれのバージョンで「廃止」があり、切り分けが困難

Rails3 rebase最終版

  • Mercurial
    • rails3-straight-20120421-1 名前付きブランチ
  • Git

viewのファイルの拡張子変更

  • .rhtml から .html.erb へ
  • Subversionとhgsubversion(後述)を経由したMercurialは ファイルの変名を追跡する
    • Mercurial上においてmerge/rebaseが可能
  • Gitはファイル名の変更を追跡しない
    • merge/rebaseはおそらく不可能

Rails3対応 2011-10-16まで

Rails3.1 進捗40% 2011-10-16

Note 27

これがかなり動いたので、これ以降github上で大勢の人の手が入り始める。

それを積極的にバックポート(特にhtml_safe)

routeその1

  • routeのテストの置き換え
    • r8201 2011-12-14 Redmine ローカル
      • Rails3.0では新旧両フォーマットで動く
      • しかしshouldaが動かない
      • routeのテストを全部置き換えてしまえ
      • 前後関係とかがパズル

routeその2

  • Note 37 2012-01-12 進捗率70%
    • Rails3フォーマットの新routeでRails3.1と3.2が 見た目上ほぼ完璧に動く

Rails3 - JPLの本気

ブランチ管理

ChiliProject

数あるRedmineの独自フォークのうちの1つ

第1回の ローカル bitbucketホスティング

ChiliProjectの活動はほぼ停止

Redmineの フォーラム より

ohloh-redmine-chili.png

Redmineの体制(2011年以降)

  • コミッタ
    • フランス
      • Jean-Philippe Lang
      • Etienne Massip
      • Jean-Baptiste Barth
    • フランス以外
      • 自分
  • コントリビュータ
    • オランダ
      • Mischa The Evil

Redmineのブランチ管理

hgsubversion

hgsubversion(+TortoiseHg)は最強のSubversionクライアント

TokyoMercurial#3 のこいんとす氏の 資料

hgsubversion-hgtk-1.4-stable-bp-graph.png

ChiliProjectの発足の理由(推測)

ChiliProjectの体制

ChiliProjectの歴史

ChiliProjectの取り込みは2011-04-03が最後

  • Redmineの1.1と1.2の中間
  • チケット61 PDFの文字化け解消が中途半端
  • Ruby1.9対応???

ChiliProjectのブランチ管理

路線図

chili-ecb29a600b5.png

Gitのブランチその1

Gitのブランチその2

  • 子孫を遡らないとブランチがわからない
  • リビジョンが複数のブランチに所属する
  • リモートの ブランチ 削除できる
    • マージコミットのログ "Merge branch xxx" が意味をなさない
    • 到達不能 リビジョンは 、1.7.3.4 のデフォルトで二週間後に"git gc"で 削除される
  • これらを防ごうとするとブランチだらけになる
    • ChiliProjectの ドイツ勢 のブランチは 2012-05-14 現在 215

acts_as_journalizedの「マージ」

chili-70e10ab4bd61.png

複雑な路線図の改善の動き

  • 2011-10-03
  • 2011-11-11 ChiliProject
    • フォーラム Merging long standing branches
    • Feature #692note-5
      • レビューが困難
        • コミットメッセージにドイツ語が入っている
        • コミットメッセージに目的を書きなさい
        • 重複しているコミットを1つにまとめなさい

Accomplished ChiliProject division - ChiliProject事実上の分裂

chili-ui-disruption.png

Mercurialのブランチ

Mercurialの名前付きブランチ

  • Mercurial本体の リポジトリ の タグ 2.2.1 近辺
  • 各リビジョンにブランチ名が埋め込まれている
    • リビジョンだけでどのブランチなのかわかる
hg-named-branch.png

Redmineのワークフロー図

redmine-workflow.png

Redmineのワークフロー

  • マスタはSubversionだが 中央集権型 ではない
  • チケット=機能ブランチ・バグ修正ブランチ
  • Mercurial・TortoiseHgはメーリングリストでレビュー
    • 自分のTortoiseHgへの投稿への 返信
  • Redmineはチケットでレビュー
    • Defect #8857 Gitの新ブランチの取り込みが重い
    • Patch #10470 Efficiently process new git revisions in a single batch

Githubを使うことの問題点その1

  • リポジトリのフォークを 1アカウントに1つしか持てない
    • リポジトリの分離 による管理が出来ない
    • ブランチだらけになる
    • 何のためのブランチなのか判断不能
      • 独自利用目的?貢献目的?
  • Bitbucket は公開・非公開に関わらず 無制限

Githubを使うことの問題点その2

  • pull requestを無効化できない
    • issueは無効化できるのに何故?

Githubを使うことの問題点その3

  • 何故Githubにアカウントを作らなければならないのか?

MercurialとBitbucket

  • Bitbucketは非公開を含めリポジトリ数・容量無制限
  • Mercurialのcloneは同じファイルシステムではハードリンク
    • "hg clone --noupdate"は一瞬
    • Gitでのブランチの容易さはMercurialではcloneの容易さ
    • 個人・組織利用目的は非公開で、貢献目的は公開で
  • MercurialはMQ(Mercurial Queues)もリポジトリ管理できる

MQ (Mercurial Queues)

ブランチ管理のまとめその1

  • Git
    • プロジェクトの性質・規模にあった管理をしましょう
  • Mercurial
    • マルチプルヘッドさえ慣れればトラブりません
    • 名前付きブランチ・MQは必須ではありません
    • シンプルが故にそのまま大規模プロジェクトでも適用できます

ブランチ管理のまとめその2

  • rebase
    • Git/Mercurialでは必須ではありません
    • しかしSubversionがマスタだと必須です
    • オープンソース・大規模プロジェクトに限らずリビジョンを綺麗にすることを心がけましょう
    • MercurialではMQを活用しましょう