はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
ちょびえです。Githubのsvnサポートが神なことに最近きがついたのでカッとなってエントリでも書いてみました。 きっとこの便利さはあんまり言及されてないはず（ワタシだけが知らんかった、とかだったらほんとすいません） https://help.github.com/articles/support-for-subversion-clients/ Githubでは上のページに書いてある通りsubversion clientのサポートもしております。 なんで今さらsubversion？という感じもする方もいらっしゃるかと思いますが。 これ、svnなので当然ディレクトリ個別にチェックアウトできるのですよね・・・・ たとえば、こんなふうにやると svn co https://github.com/chobie/flatbuffers/trunk/php flatbuffers-php A flat
巨大な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
Gitがよく取り上げられていますので、少し長いですが、概念だけでも簡単に掴みたい方のために資料を作ってみました。 Gitがここまで広がった要因にはGitのみならず、GitHubやそのクローンが持っているPull Requestの仕組みの影響も大いにあると個人的には考えています。が、まずは簡単にGitとはどんなものかをまとめたいと思います。 どうしてGitなのか、Gitのメリット SubversionとGitの違い ローカルでGitを使ってみる Gitサーバーのある構成管理 1.どうしてGitなのか、Gitのメリット 最初にGitのメリットを明確にしておきましょう。Gitは分散型の構成管理システムとよく言われます。この「分散型」「構成管理」の意味を理解するのがGitを使う上で最大のポイントになると思います。 この記事をお読みの方は既にSubversionなどサーバーによる構成管理を導入されて
気がついたら Git を初めて触ってからもう5年近くになってました。 それまで使ってた Subversion はもう全然使ってなくて、もう svn のサブコマンドは ls, log, co くらいしか使えません。Subversion のリポジトリを見ないといけないときは、とりあえず git svn で Git リポジトリに変換してから見たりしてます。 SCCS, RCS, CVS はもう全然わからないので、Subversion はまだ覚えてる方ですけど…。 Subversion に対する Git の利点はあちこちで述べられているので今更何も書くことはありませんが、Git よりも Subversion の方が良いこともあるので、忘れないうちに書いときます。 リポジトリ全体をコピーしなくても編集できる リポジトリの歴史が長い場合や、頻繁に更新されるバイナリデータがあるとリポジトリが大きくなりま
Clojure's Journey: From Simplicity to Enterprise Maturity Jordan Miller discusses the evolution of the Clojure ecosystem, from Rich Hickey's initial vision tackling complexity to its current status as a mature enterprise solution. He explains key philosophies, highlights pivotal moments like the "Simple Made Easy" talk, and showcases the vibrant Clojure community and its innovative tools.
2011年4月18日(火)に実施した、プライベートセミナー『アジャイル開発環境セミナー～一般ユーザが知っておきたいJIRAの概念と操作～』での資料です。
勉強と備忘録として 前提 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 /
仕事ではSubversion（以下、svn）を使っているのだが、これをgitに置き換えたい。 とはいえ、いきなり全体をgitに移行するのはキツそうなので、以下のようなプロセスを踏もうと思う。 (1) 自分の環境だけgitを使えるようにする（中央リポジトリはsvn） (2) 他のメンバー（数名規模）もgitを使えるようにする（中央リポジトリはsvn） (3) 中央リポジトリをsvnからgitに変える このエントリでは上記(1)の経緯を書きとめておく。 現状 ・以下のように中央にsvnリポジトリが存在していて、各人がそこからチェックアウトしている ・各人はチェックアウトした「svn作業コピー」から「作業用ディレクトリ」にコピーしている（cpやrsyncで） ・各人の「作業用ディレクトリ」のhtdocsはdev環境としてブラウザから閲覧可能 ・各人の「svn作業コピー」と「作業用ディレクトリ」は
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2013 年 1 月 22 日 "From SVN to Git: How Atlassian Made the Switch Without Sacrificing Active Development – the Technical Side" このポストは、エンタープライズ開発のバージョン管理を Git に切り替えることに注目した連載記事（全三回）のうちの第二回目として、 Dr.Dobb's で紹介されました。最初の記事では、 今日、これほど多くのチームが切り替えを決断している理由 について議論しました。今回の記事では、アトラシアンが行った Git への切り替えにおける技術的な側面に焦点を合わせています。 この三部からなるブログシリーズでは、アトラシアンが行
1) Gitlab was chosen as an alternative to GitHub Enterprise due to its web UI, pull request functionality, and the fact that it could be maintained by GREE Tech's 80 Ruby engineers. 2) The company transitioned from Subversion to Gitlab by using git-svn to allow cross commits between the two systems during a period of combined use. 3) The speaker felt pull requests promoted a better development cul
*本ブログは 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
SVNからgitに移行してみようかなーと思ってネットで見つけた手順をやってみたのだけれど、自分の知識レベルではそれぞれのコマンドが何を意味しているか理解するのに時間がかかったので、この苦しみをあとで理解できるように簡単にまとめてみた。 前準備 gitとgit-svnのインストールを済ませておくこと。 適度なSVNリポジトリがなかったので、昔使っていたGoogle CodeのSVN（http://daipresents.googlecode.com/svn）を変換している。 1コマ目：SVNからGitに変換する https://gist.github.com/daipresents/05c7c4667d7e80a280a229b2b33b872c.js?file=gistfile1.txt SVNからgitに変換する。変換したgitリポジトリをsvn2gitとかいう名前にしている。途中でコケ
動機 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・Git・Mercurialの比較のために過去の記事や関連資料をリンクしておく。 【比較】 SVN / Git / Hg 比較表 ? TortoiseGit Japan 【Subversion】 Subversion によるバージョン管理 svnbook.ja.pdf Subversionを見直せ: プログラマの思索 Subversion/運用方法 - ピノキヲ IT Wiki 【Git】 Pro Git 日本語版: プログラマの思索 A successful Git branching model: プログラマの思索 git-flow による構成管理とRedmineの関係: プログラマの思索 【Mercurial】 Mercurialの資料: プログラマの思索 hgbook 日本語版のHTML公開: プログラマの思索 CVS→SVN→Git・Mercurialへ至る歴
SubversionからGitへ移行するときに起こる問題についてちょっと語りました。
This site uses cookies to improve your customer experience. For more details please read our Privacy Policy. The ultimate solution for SVN to GIT migration Works on all platforms! Choose yours. TMate SubGit is a tool for teams that migrate from SVN to Git. It converts SVN repositories to Git and allows you to work with both systems simultaneously. GET STARTED Create an SVN || Git Mirror with SubGi
社長におねだりしたらベイスターズ買ってくれないかなぁ。どうもこんにちは nakamura です。 シーブレインでは今も昔もソース管理に Subversion を使い続けていますが、最近は協力会社さんとのやり取りなどで何かと Git にさわる機会が増えてきました。最初はチンプンカンプンでしたが、ようやく何となく基本的な部分が分かってきたので、Subversion ユーザ的な目線でちょこっと説明してみたいと思います。 コマンド例 初期設定 Git ではユーザ毎の設定内容も git コマンドで操作します。とりあえずいつも以下のような感じで設定してます。diff に使うコマンドとかも指定できるみたいですね。 # 名前 git config --global user.name "Tadashi Nakamura" # メールアドレス git config --global user.email n
Subversionにおけるブランチとは、ディレクトリのことである。 Subversionにおいては、ブランチとは単なるディレクトリに過ぎません。 Subversionではよく下記のようなツリー構造にすることが推奨されます。 project - trunk - branches - foo - bar ブランチfooやブランチbarは、たいていtrunkディレクトリをコピーして作ります。 「ブランチを作成する」という行為は「ディレクトリをコピーすること」と操作的には同じであり、１コミットとして扱われます。 $ svn cp svn://path/trunk svn://path/branches/foo -m "make branch" 「ブランチの名前変更」も「ディレクトリのリネーム」と同じ操作であり、やはり１コミットして扱われます。 $ svn mv svn://path/branch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
