こんにちは、今年は2017年ですね。tanakaです。 このたび、2009年からコミット履歴のあるプロジェクトのSVNリポジトリをようやくGitに移行しました。 その手順やハマリどころについてまとめておきたいと思います。 移行前と移行後の制作フローとか このSVNリポジトリは、開発用ブランチ trunk とリリース用ブランチ branches/RB の2本が常設してあり、 trunk でリリース可能になったコミットだけをCherry pick で branches/RB にマージする運用をしており、 マージしないコミットが増えると衝突が発生したり、時間経過で差が増えていき辛い感じになってました。 そこでGit(GitLab)に移行することにしました。 移行にあたり、ブランチ戦略としてGitHub Flow を導入しました。 master への直接のプッシュは禁止し、すべてマージリクエストで
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
「GitHub Enterprise 2.5」リリース。数万人の大規模な開発チームにも対応するクラスタリング構成、アクセスの集中にはキャッシュインテンシブな処理で対応 GitHubは大規模な組織での利用にも対応したソースコード管理ソフトウェアの新版「GitHub Enterprise 2.5」のリリースを発表しました。 GitHub Enterprise 2.5の最大の変更点は、大規模な開発チームでの利用にも対応するようにクラスタリング構成によるスケールアウトが可能になったことです。 ただしクラスタリングは非常に大規模な運用向けに特別に設計されているため、管理リソースの追加も必要となるとのこと。 また、GitHub Enterprise 2.5では内部的にキャッシュインテンシブな処理を実現し、大量の開発プロジェクトを抱えていたり、大規模な継続的インテグレーションなどによって集中的にソースコ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? このページについて 中央集権型バージョン管理のCVSとSVN、分散バージョン管理のGit両方を各プロジェクトで使用してきた経験から、新規開発、保守開発でSVNを使用し続けているプロジェクトがGitを使うメリットについて考えて書いてみるページです。 あくまでも経験を下に主観で書いていきますので、いやいやその考え方は間違っているよ！とか、これも書いといて！というのがあれば、コメントやら編集リクエストなどください。 想定読者 Gitを使ってみたいけど、保守開発だからSVNからGitに乗り換えるのなんて無理だよ！と半ば諦めている方 SVNからG
巨大なSubversionリポジトリをGitに移行しようと思ったのですが、git-svnが遅かった。 SubGitというのを見つけて使ってみると速かった。 www.subgit.com Java1.7以降が必要。 雰囲気はこんな感じ。svnリポジトリからgitのbareリポジトリが吐き出される。 そのままGitBucketのリポジトリ置き場においても良い。 % ~/Downloads/subgit-3.0.0/bin/subgit configure /path/to/svn/repo SubGit version 3.0.0 ('Bobique') build #3320 Configuring writable Git mirror of remote Subversion repository: Subversion repository URL : /path/to/svn/rep
「Upsource 1.0」は、VCSレポジトリ全体を閲覧可能で、社内のレポジトリとGitHubのような外部レポジトリを同様に扱える。 コードレビューツールとしては、リビジョンの判別やインラインまたは横に並べての比較、最近のコミット／ブランチ／マージの追跡、プロジェクトで何が行われてきたかを確認する機能を搭載する。また、現在作業中のコードや、もっとも最近に作業を行ったコードにすばやくアクセスでき、文字列のハイライト機能や、コード／ファイル／テキスト検索機能によって、プロジェクト全体を把握しやすくしている。 このほか、チームメイトと議論しながらコードの編集が可能で、リビジョン単位またはブランチ単位でのコードレビューの作成や、チーム全体での重要なコードベースの変更の共有ができる。さらに、リビジョン／ブランチ／コードレビュー／差分／議論／レポート／検索フィルタ／ファイルなど、コードのあらゆる箇所
ルーキーは2014年2月3日、プロジェクト管理ソフト「Redmine」とバージョン管理ソフト「Subversion」をSaaS型で提供するサービス「Rookie Saas Redmine」を発表した。同年1月20日から提供を開始している。OSS（オープンソース）開発用途の無償コースと、一般用途の有償コースを用意した。 Rookie Saas Redmineは、Web型で動作するプロジェクト管理ソフト（Redmine）とバージョン管理ソフト（Subversion）を、月額制のSaaSとして提供するサービスである。ソースコードの開発用途に加え、業務プロジェクトの進ちょく/タスク管理やオフィス文書のバージョン管理に利用できる。なお、RedmineとSubversionは、いずれもOSSである。 用途に応じて、二つのコース（ライセンス）を用意した。「スタンダード」コースは、一般企業向けの有償コース
diffビューア/マージツールのMeldの開発者は7月28日、最新安定版「Meld 1.7.4」をリリースした。「Subversion 1.8」のサポートなどが特徴となる。 Meldはファイルやディレクトリの比較ができるGUIツール。2方向および3方向での差分表示が可能で、Git、Bazaar、Mercurial、Subversionなど主要なバージョン管理システムをサポートする。視覚的に分かりやすいUIを特徴とし、自動マージ、リアルタイムでの比較情報アップデートなどの機能を備える。多くのLinuxディストリビューションで公式パッケージとして提供されているほか、WindowsやMac OS Xでも動作する。 Meld 1.7.4では、コミットダイアログがコミットメッセージを自動で内包するようになったほか、フォルダ比較でもリアルタイム検索を利用できるようになった。また、6月に公開されたSub
勉強と備忘録として 前提 SSHでログインできるサーバーに中央リポジトリを置き、リモートで作業するモデルを想定。 サーバー：servername.hoge.jp Subversionリポジトリ /path/to/repos Gitリポジトリ /path/to/repos.git クライアント 作業ディレクトリ /path/to/works リモートリポジトリの作成 Subversionコマンド サーバーにて % svnadmin create /path/to/reposクライアント側にて % cd /path/to/ % svn import works svn+ssh:///servername.hoge.jp/path/to/repos/works -m "Comment"Gitコマンド サーバーにて（参考: Gitリモートリポジトリ構築 CapmNetwork） % mkdir /
2011年4月18日(火)に実施した、プライベートセミナー『アジャイル開発環境セミナー～一般ユーザが知っておきたいJIRAの概念と操作～』での資料です。
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 3 日、Jonathon Creenaune 投稿 “From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development“ このポストは、エンタープライズ開発チームが Git に切り替えることに注目した連載記事の一つとして、Dr.Dobb’s で紹介されました。 アトラシアンでは、ここ何年もの間、DVCS に熱狂していました。私たちは DVCS に多額の投資を行ってきたのです。Bitbucket (クラウド DVCS リポジトリのホスト) を買収し、Stash (社内環境での Git リポジトリマネージャ) を開発しました。さらに、Fish
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
チェコTMate Softwareは9月24日、SubversionからGitへのマイグレーションを容易にするツール「SubGit 1.0」を公開した。SubversionリポジトリとGitリポジトリを双方向にレプリケーションする機能を持ち、既存のSubversion環境を変更なしにGitからアクセス可能にするという。 SubGitはJavaで実装されたツールで、SubversionレポジトリをGitリポジトリにマイグレーションする機能を持つ。また、SubversionとGitを併用するための同期機能も備えている。Gitには同様の機能である「Git-Svn」が含まれているが、これと比べた優位点として、レポジトリのクローンが不要な点、Gitレポジトリに対してコミットでき両者間の変換は最小限で済む点、SubversionとGitの両方の機能をすべて利用できる点、さまざまなツールを利用できる点な
あるユーザーの方から、Subversionとの連携について問合せをいただきました。 astah*のプロジェクトファイルを Subversionで管理している過去のリビジョンと比較できないか、という内容です。 今日は TortoiseSVNでの設定内容を紹介します。 （プロジェクトの簡易比較は、astah* professionalで利用できます。） ----------------------------------------------------------- 1. [TorsoiseSVN]-[設定]を選択します。 2. [外部プログラム]-[差分ビューア]を開き、[高度な設定]ボタンを押下します。 （画像は Windows7で設定ダイアログを開いた状態です） [siteimg align=left]uploads/thumbs0/1150.png[/siteimg] 3. [差分
InfoQの分散バージョン管理の記事を読んだ後に、もう一度、JoelがMercurialについて書かれた記事を再読して、ようやく分散バージョン管理が従来のバージョン管理ツールと何が違うのか分かったのでメモ。 ラフなメモ書き。 殴り書きの部分は後で直す。 【元ネタ】 分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project JoelもMercurialを使っている: プログラマの思索 InfoQ: エンタープライズ分野での分散バージョン管理システム 分散バージョン管理の可能性: プログラマの思索 (前略) 分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。 重要なのは、このシステムが「バージョン」ではなく「変更」(注釈：リビジョン)で物事を捉えているということだ。 (中略) Subvers
There are many people who want to use Git, but are forced to stick with Subversion for various reasons. Git-svn gives us the opportunity to migrate away from Subversion, but setting up a two-way sync is less than trivial. On this page I've documented the best way I've found so far for how to live with Git and Subversion in parallel.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く