つまみ食いとか青田買いといわれる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の直下に
Benjamin Pollack、 2009 年 10 月 24 日、 原文 (original post) Kiln が Mercurial を選択した理由を疑問に思うなら、つまり質問は 2 つあるということです。 Kiln が DVCS ベースな理由は? Kiln があえて Mercurial を選択した理由は? Kiln が DVCS ベースな理由は? DVCS が本物のブランチをサポートしているからです。 ご存知のとおり、 Subversion や CVS の様なツールでブランチをマージしようとすると、 まず間違いなくかなりイライラさせられてしまいます。 Subversion 1.5 以前はマージ履歴を全く記録しておらず、 また、最新版でさえそのメタデータを上手く活用できていないため、 マージはいつも途方もない労力を要し、間違いだらけのプロセスで終わるのが落ちだからです。 こうして
こんにちは、熊谷です。 今まで長い間バージョン管理システムとしてSubversionを使っていました。特に不満もなく使い慣れているシステムなのでずっと使っていたのですが、あるとき、こういう環境でSubversionを使うのはちょっと不便かもしれないという状況が生まれ、いろいろ考え調べてみた結果、gitが使えるのではないかという結論に達しまして、早速使ってみました。 そもそもSubversionとgitの違いは何なのか。Subversionは集中型、gitは分散型のバージョン管理システムで、Subversionは中央のリポジトリに対してコミットを行っていくのですが、gitは各ユーザが持つローカルのリポジトリに対して行います。そして、ローカルのリポジトリの内容を中央のリポジトリに反映したり、別のユーザが持つリポジトリを取得したり反映したりといったことが出来ます。 また、既にSubversion
Subversion is an open source version control system. 17日(米国時間)にSubversionプロジェクトがApacheプロジェクトのもとでトッププロジェクトとして認定されたと発表されている。名称が『Subversion』から『Apache Subversion』となるほか、ホームページもhttp://subversion.apache.org/へ変更となる。Subversionは2009年11月にApacheプロジェクトへ提案されている。4ヶ月ほどでトップレベルプロジェクトへと昇格したことになる。 SubversionはOSSで開発されているバージョン管理システム。CVSの問題を解決するべく開発されたシステムで、CVSにおける問題のいくつかが解決している。操作方法がCVSを踏襲していることからCVSから乗り換えるプロジェクトも多く、発表
Bazaar 2.1 がリリースされました。まだソースコードのみですが、ここからダウンロードできます。 Bazaarは 2.0 のリリース からUbuntuのような半年ごとのリリーススケジュールに移行していて、ほぼスケジュール通りのリリースとなりました。 今回も、私の基準でこの半年間のBazaarやその周辺の改良を紹介しておきます。 Bazaar本体の改良 まずはbzr本体の改善点です。 bzr+ssh でも bzr+sftp のように、 ~ でホームディレクトリを指定できるようになりました。 自分のホームディレクトリ以下にリポジトリ置き場を持っている人は、 bzr+ssh://host/~/bzr/proj/branch の用に短いURLを利用できるようになります。 メモリ使用量や速度が向上しました。特にタプルというPythonの軽量なデータ構造をさらに軽量にしたStaticTupleの
404 file not found We're sorry! The page you requested cannot be found. You can Search to find the correct url. For software licensing,website privacy policy, website terms of use, and legal FAQs, please see our legal stuff page. Eclipse logos and graphics are found on our logos page. For problems with the eclipse.org site, please contact the webmaster or read the webmaster FAQ for answers to comm
郷古です。 On 2012/04/24, at 1:42, INADA Naoki wrote: > ありがとうございます。手順はそのままで結構です。 > そもそも日本語訳のベースが古いので
きっかけ。 元ネタ。 俺はVSSを使用しようというプログラマを信用しない。（と宣言しておく） 割と適当訳なのでご了承ください。 時々現れる、どのバージョン管理ツールをつかうのかという宗教的議論の中で、 私はマイクロソフトのVisualSourceSafeが一貫して叩かれている事に気付きました。 私はこれほどまでに憎悪を集めるような別のソフトウェアプロダクトを考えることができません。 私のプログラミングキャリアの日々では幸運なことに、svnを使う場所で働いていおり、さらに最近ではgitだったので、私はVSSを一度も経験したことがないということです。 VSSは本当に皆が主張するくらいに悪いものですか？ はい、そのとおりです！！ 私はgit、svn、cvs、tfs、及びvssを使いましたが、VSSは最も悪かったです。 それには、みんなで作業を分離するという概念が全くありません。 ファイルを操作す
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
GourceはWindows/Mac OSX/Linux向けのオープンソース・ソフトウェア。ソフトウェア開発とはクリエイティブな作業であり、まるで生き物のように成長していく。自作のソフトウェアを我が子のように可愛がる人がいるのも理解できる。 バージョン管理をビジュアル化 そんなソフトウェアの歴史を管理するのがバージョン管理だ。そしてそこに残されたコミットログを使ってビジュアル化するソフトウェアがGourceだ。GourceはGit/Mercurial(Hg)対応のバージョン管理ビジュアル化ソフトウェアだ。 ビジュアル化に何の意味があるかと言われればたいした意味はない。だが一度実行すると時系列に沿ってどんどん成長していく様が面白く、飽きさせない。なお追加のステップを踏めばCVS/Subversionにも対応するらしい。 爆発的に開発の輪が広がっていく まるで木のように成長していくのは、まさに
こんにちは、今年10月に入社したgaoohです。 普段はブログ周りの開発をやってます。 今回ブログの開発グループはソース周りの管理をsvnからgitへ移行したのでgitについて書いてみようと思います。といってもgitに関しては多くのエンジニア系のブログなどで解説されているので、基本的な使い方ははしょります! 今回はgitをより便利にしてくれるgitconfigについて書いてみます。 gitconfigとはgitを利用するための共通設定ファイルですね。 ちなみに私の ~/.gitconfigファイルは以下のようになってます。 [user] user = gaooh email = xxxxxxxxxxxxxxxx [color] status = auto diff = auto branche = auto [alias] co = checkout ci = commit -a st =
分散バージョン管理システム「Git」は、SubversionやCVSのように中央サーバを必要としないため、より柔軟な運用が可能になっている。本記事では、Gitのこういった特徴をいくつか紹介する。 Gitは数多くの企業やプロジェクトの間で近頃急速に人気が高まってきている分散バージョン管理システムである。GitHubサイトを見てもらえれば、たくさんのプロジェクトがこのサイトを利用していることがわかるはずだ。 数多くのプロジェクトが、CVSやSubversionのような「従来型の」バージョン管理システムから、柔軟性の高さと機能の豊富さに惹かれてGitに鞍替えしてきている。 Gitには「分散型である」という大きな特徴がある。これはつまり中央サーバが不要であるということを意味している。GitはSubversionとは異なり、オンラインであるかどうかにかかわらずリポジトリにコミットすることができる。つ
Mercurialといえば、gitと並んでよく使われている分散型バージョン管理システム。Google Codeやsourceforge.netでも利用可能である。 そしてMercurialと言えばpythonで構築されている事でも有名である。 ただ、pythonであるがために、ソースに手を入れ辛い(それ以前にpythonをよく知らない)、文字化け等でトラブった時もなかなか対応できないという事もままあったりする(pythonを勉強したら済むと言えばそれまでだが) そこで登場するのが、今回紹介するAmp。Mercurialのコマンドであるhgの100%互換を謳っており、Rubyで書かれている 。このRubyで書かれている事が重要。ちょっとソースを覗いてみようか、という気になるし、カズタマイズやトラブルシューティングも(Mercurialよりは)楽にできるはず。 Ampとは Rubyで書かれたM
ども。自分のサイトを復旧させるのが面倒なため会社のブログに本のレビューまで乗せようという魂胆の村瀬です。 週末に「入門GIT」を読んだのですがこの本は git ユーザーはもちろんのことその他すべての開発者が必読の本だなぁと感じたので紹介しておきます。 この本です。 この本は現在の git の開発者でありメンテナーである濱野氏によって書かれた git の入門本です。 ただの入門本にあらず しかし入門本だから最初はよくあるようなチュートリアルのような記事からはじまるのだろうと思っていると最初から面食らいます。 最初に書かれているのは git がどのようにデータを記録し、どのように履歴をたどれるようになっているかというまさに git 自体の基本が書かれているのです。 僕個人は二年近く git を使用してきているため自分の知識の確認のような感じで読み進められましたが、初めての方はすこしむずかしいか
Bazaar is a version control system that helps you track project history over time and to collaborate easily with others. Bazaarの最新版となるBazaar 2.0.0が公開された。Bazaarは分散バージョン管理システム。従来の集中バージョン管理システムのように扱うこともでき、さらに参加しているメンバーとのコラボレーションを簡単に実現できるという特徴がある。 Bazaar 2.0.0ではバグ修正と安定化に主眼をおいたリリース。また、1.16で導入された2aフォーマットが新しくブランチを作ったりリポジトリを作る場合のデフォルトのフォーマットになっている。a2フォーマットはほとんどの操作においてサイズが小さくより高速に動作するとされている。 バージョン管理システムには大
OpenOffice.org - The Free and Open Productivity Suite a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects. Sun Microsystems、Jens-Heiner Rechtien氏がOpenOffice.org development switches to Mercurialにおいて、5ヶ月におよぶ作業の結果、OpenOffice.org開発のブランチをMercurialへ移行する準備が整ったと伝えている。MercurialはPythonで開発された分散型バージョン管理システム。OpenOffice.orgに限らず、有名プロジェクトのいくつかはM
入門GitはGitのメンテナである濱野さんが書いただけあってGitの本質がわかりやすく記されている。 バージョン管理システム(VCS--Version Control System)としてCVSやSubversion(SVN)があるし、分散型VCSとしては、Git以外にもいろいろあるが、まあGitでいいのではないかと。なんといってもLinuxで利用されているという圧倒的な実績。数千人規模のプロジェクトで利用できるスケーラビリティ。そのような規模では、もはやSVNのような集中型VCSではスケールしないというのはあきらかだろう。 VCSの解説は、細かい機能というよりも、そのツールを利用してのプロセスやワークフローあるいは利用しているコミュニティの文化なんていうものを、わたしは理解したいので、その意味で本書は濱野さんの経験からでる貴重なノウハウがつまっている。 Gitなどを使った共同開発の基本的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く