SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
Subversionを使用し続けているプロジェクトがGitに移行することを考えてみた - Qiita
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へ変更して感じたこと - torutkのブログ
少人数チームでのソフトウェア開発でソースコードを管理するリポジトリにGitを適用して1,2ヶ月ほど経過しました。Gitを開発に使用するのは今回が始めてで、みなSubversionを使っていたメンバーです。 開発環境 OS Linux、たまにWindows 開発言語 Java プログラミングツール NetBeans 7.4 Gitクライアント NetBeans標準搭載のGit機能、たまにコマンドライン、WindowsではたまにTortoiseGit Gitサーバー apacheでgit-http-backend、Redmineと認証統合 現在の使用状況 Gitの共有リポジトリを、開発サーバー上にapache（HTTP）でホストしています。 共有リポジトリはmasterブランチ一本で、各メンバーはローカルにcloneしたあとローカルのmasterで変更作業を実施し、適宜共有リポジトリのmast
GitとSubversionを併用する - maeharinの日記
仕事ではSubversion（以下、svn）を使っているのだが、これをgitに置き換えたい。 とはいえ、いきなり全体をgitに移行するのはキツそうなので、以下のようなプロセスを踏もうと思う。 (1) 自分の環境だけgitを使えるようにする（中央リポジトリはsvn） (2) 他のメンバー（数名規模）もgitを使えるようにする（中央リポジトリはsvn） (3) 中央リポジトリをsvnからgitに変える このエントリでは上記(1)の経緯を書きとめておく。 現状 ・以下のように中央にsvnリポジトリが存在していて、各人がそこからチェックアウトしている ・各人はチェックアウトした「svn作業コピー」から「作業用ディレクトリ」にコピーしている（cpやrsyncで） ・各人の「作業用ディレクトリ」のhtdocsはdev環境としてブラウザから閲覧可能 ・各人の「svn作業コピー」と「作業用ディレクトリ」は
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
SubversionとGitリポジトリを両方利用できるようにする·SubGit MOONGIFT
SubGitはSubversionとGitの二つを利用できるようにするソフトウェア。 SubGitはJava製のフリーウェア。企業においてはSubversionが使われることが多い。だが個人の開発者や新しいプロジェクトからはGitを使っていこうという動きも見られる。とは言え新しいバージョン管理を覚えるのも大変なことだ。 実行中 発言力をもったメンバーがSubversionでいいじゃないかと言ってしまえばGitへの移行もおいそれと実現しないだろう。そこで使ってみたいのがSubGitだ。 SubGitは既にあるSubversionのリポジトリをGit化してしまうソフトウェアだ。移行するのではなく、両方が共存できるようにしてしまう。Java製のプロキシサーバ的なものがローカルに立ち上がる仕組みになっている。これがGitとSubversionの仲介役を務めるのだろう。 さらにSubversionリ
私がSubversionをやめてGitに移った理由 | エンタープライズ | マイコミジャーナル
Javalobby - The heart of the Java developer community バージョン管理システムにGitやMercurialなどの比較的新しい分散型バージョン管理システムを採用する事例が増えている。もともとOSSプロジェクトで採用するバージョン管理システムは中央集権型のCVSが多かった。しかしCVSは厄介な面もあり、こうした問題を解決した同じく中央集権型のSubversionがCVSの次期候補として注目されていた。 CVSからGitへ、Fedora 13以降 止まらないGit人気、JRubyも移行 - 対抗馬はMercurial Git人気が止まらない、今度はGnome Gitバージョン管理システム採用拡大、Perl 5も移行 7つのバージョン管理システムを知る しかし現在のところ、バージョン管理システムは分散型のMercurialとGitに注目が集まって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting…
GitとSVNに対応可能なプロジェクト管理ツール「Springloops」 | Web活メモ帳