募集頁:http://kokucheese.com/event/index/6329/ ハッシュタグ: #shibutra 2010年12月17日(金) (19:00-22:00 (開場18:45)) 開催場所 古石場文化センター 2階 第1,2研修室 (東京都江東区古石場2-13-2) 続きを読む
募集頁:http://kokucheese.com/event/index/6329/ ハッシュタグ: #shibutra 2010年12月17日(金) (19:00-22:00 (開場18:45)) 開催場所 古石場文化センター 2階 第1,2研修室 (東京都江東区古石場2-13-2) 続きを読む
Gitの使い方について良い記事があったのでメモ。 【元ネタ】 見えないチカラ: A successful Git branching model を翻訳しました 少人数開発に役立つ5つのまとめ 構成管理について良い本は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」と「入門Git」の2冊。 これらの本を読んで理解した立場から書いてみる。 GitやMercurialのような分散バージョン管理では、ブランチをたくさん作るのが普通。 ブランチの目的を意識して、ブランチを管理するのが重要。 上記の記事では、メインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類が紹介されている。 僕の理解では、記事に書かれているメインブランチはtrunk、フィーチャーブランチはトピックブランチ、リリースブランチはまさ
TortoiseHg+hgsubversionの導入方法の記事があったのでメモ。 【元ネタ】 hgsubversionの導入 - 文殊堂 Gitはgit-svnという優れたツールがあるが、Mercurialはhgsubversionを使うといい。 但し、結構はまる。 上記の方法を試すと良いと思う。 git-svnやhgsubversionの利点は、中央集権SCMであるSVNをあたかも分散バージョン管理のリポジトリかのように扱えること。 マスターリポジトリはSVN、開発者のプライベートブランチはGitやMercurialと使い分けて、trunkから派生させて機能追加して実験したり、トピックブランチ上でパッチを作ったり、色々試せる。 特に、修正の順序とリリースの順序が異なる障害修正のパッチを従来よりも楽にコントロールできるのはよい。 Mercurial以前と以後のチケット駆動開発: プログラマ
ネットワークがつながらない状況での分散開発はどうやるのがいいかを考えてみる。 以前似たような経験したのは自分たちが複数の協力会社の1つという立場で、元請けのSVNリポジトリに直接コミットするというもの。ネットワークはつながっています。また元請けは基本的に開発はしておらず、協力会社も開発はほとんど終わっていて変更はバグ修正のみという状況です。 イメージはこんな感じ。 リリース(元請けのSVNリポジトリに直接コミット)する場合は、自分たちのSVNリポジトリにタグうってexportして、あらかじめチェックアウトしておいた元請けのSVNリポジトリのソースに上書きしてコミットします。この辺もHudsonで自動化してましたね。あとコミットするファイル一覧も出しました。元請けはそれと実際にコミットされたソースとを比較して漏れが無いか確認してたみたいです。 しかしこの方法だとファイルの削除やリネームに対応
夏休み突入しました。周りでは突入出来てない人もいるけど。。。--); ネットワークがつながらない状況での分散開発をマジにやりそうなので、それにそなえてHgSubversionを調べてみました。 開発者はSVNしか意識しないで、構成管理担当者がcloneして差分をbundleファイルでやりとりするのをイメージしてます。 svn diffのやり取りでもいけるかもしれませんが、まずはMercurialとSubversionの連携をやってみます。 試したOSはWindows Vistaです。 1.インストール Subversionは http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11151&expandFolder=11151&folderID=91 からSetup-Subversion-1.6.6.msiをダ
概略 hgsubversionではhg mergeしてできたmerge済みrevisionをpushすることはできない。 hg mergeしたら merge前revisionにhg update merge済みrevisionでrevert hg commit とやって同内容の非merge revisionを作ってそれをpushすれば良い。 せつめー 黄色のbranchから黒のdefaultにmergeするとする。 まず、TortoiseHGで普通にmergeする。 確認ダイアログでlocal:default,other:branchとなっているようにすること merge直後の状態はこのようになる。 hgsubversionではhg mergeしてできたmerge revisionをpushすることはできないので、 defaultのmerge直前revisionにhg updateし、 m
We Trust? 信仰してますか? ということで、今年も Definitive. Advent Calendar 2023がリリースされました。 去年は飲みたい豆からつまみ食い的に選んでしまったため、最後に残った Don Benjie Rum Barrel Aged を飲んだのは3月くらいでした。 今年は同じことを繰り返さないよう、毎日順番にブラインドで飲むことにしました。その都度簡単なメモを残すようにして、この記事で公開し、そのあとパナ氏から8日分の正解を教えてもらって答え合わせする、恥晒し企画です。 アドベントカレンダーは超信仰を選びました。対戦よろしくお願いします!!! Cold Brew (水出し) 2.0 アイスコーヒー 2.0を書いたのが 2020 年の夏なので、そこから 2 年も経ってしまったなんて驚きだ。 今回も懲りずに「2.0」シリーズを書いていくんだけど、なんで Co
つまみ食いとか青田買いといわれるcherrypickingはある特定のコミットをブランチから抜き出して別のブランチに反映させるというものです。 Subversion, Git, Mercuriaそれぞれのやり方を調べてみました。 まずSubversionいってみましょう。 準備 $ svnadmin create repos $ svn checkout file:///tmp/repos work Checked out revision 0. $ cd work/ $ svn mkdir tags branches trunk A tags A branches A trunk $ svn commit -m "add initial dir" Adding branches Adding tags Adding trunk Committed revision 1.trunkの直下に
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
分散バージョン管理Git/Mercurial/Bazaar徹底比較:ユカイ、ツーカイ、カイハツ環境!(3)(1/5 ページ) Subversionとは一味違う「分散バージョン管理」とは? 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion(以下、SVN)と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式(または、集中型)のバージョン管理システムと分散管理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く