Subversion 1.8リリース、まだまだSVNは死なない 81
ストーリー by hylom
Subversionも悪くない物ですよ 部門より
Subversionも悪くない物ですよ 部門より
insiderman 曰く、
先日、Subversion 1.8がリリースされた（SourceForge.JP Magazine記事）。これにあわせて、本家/.で「Subversion 1.8がリリースされたけど、まだGitを使うの？」という記事が上がっている。
近年ではGitユーザーが増えているが、Subversionはまだ死んだわけではなく、開発はそれなりに活発に続いている。 Apache Software Foundationの前チェアマンであるGreg Steinによると、「Subversionは1TBのリポジトリがあったとしても、その一部だけをチェックアウトして作業できる。（Gitのように）リポジトリのフルコピーは必要ない」「Gitの場合、リポジトリがたくさん乱立する傾向があるが、Subversionは基本的に1つだけだから管理もバックアップもやりやすい」などとSubversionのメリットを主張。
また、Subversionは現状オンラインでないとコミットできないが、現在オフラインでもコミットをできるようにするための機能を実装しているという。この機能は「checkpoints」と呼ばれているそうだ。
オフラインでのコミットが便利という理由だけでSubversionからGitへと移行した人も多そうなので、checkpoints機能の実装は大歓迎だ。Gitへの移行を考えている人は、もうすこし待ったほうがよいかもしれない。ただ問題は、それが利用できるようになるのがいつになるか分からないということだが……。
意外と地味に改良が続いてていい (スコア:5, 興味深い)
Git/Mercurial何かだとマルチバイトのファイル名どうすんだよって揉めてますが
Subversionは初めからUnicodeだし
Subversionで管理してるディレクトリコピーしたら.svnがくっついてて大変なことになった
って問題は、1.7でルートだけに.svn作るワーキングコピーの形式になって助かったし
ちょっとずつ改善されていってる感がいいです。
後は、依存ライブラリを減らしていってくれればまだまだ戦えるバージョン管理ツールです。
Re:意外と地味に改良が続いてていい (スコア:3)
> Subversionで管理してるディレクトリコピーしたら.svnがくっついてて大変なことになった
subversionで管理しているなら export コマンドが便利ですよ．
コマンドラインからだと
$ svn export リポジトリのURL コピー先ディレクトリ名
です．
これで .svn のくっついていないディレクトリコピーが作れます．
Re: (スコア:0)
いやぁ、そのコマンドを使わなきゃダメってところが不便だったんですよ。
Re:意外と地味に改良が続いてていい (スコア:1)
Subversionは自分の好みに合ってるんだが、問題は対応してるリポジトリサービスが少ないことかな。まあ、ローカルに構築してしまえばいいんだが。
Re:意外と地味に改良が続いてていい (スコア:1)
Macから濁点や半濁点を含むファイル名をコミットされてハマったことありませんか?
# Unicode時代のダメ文字に認定したい
Re: (スコア:0)
Git/Mercurial何かだとマルチバイトのファイル名どうすんだよって揉めてますが
Subversionは初めからUnicodeだし
同意。Unicodeは好きじゃないけど、今時文字コードどうすんだよって悩みたくない。
実質Windowsの一人勝ちなんで、Unicodeで困ることも少ないし。
後は、依存ライブラリを減らしていってくれればまだまだ戦えるバージョン管理ツールです。
よくわかってないかもしれないけど、ruby-1.9.3以降で使えるWindows用Rubyバインディングバイナリが欲しいんだけど、ものすごく古いruby用のしか見つからない…
Re:意外と地味に改良が続いてていい (スコア:1)
互換性のためにいつまでたってもShift_JISを捨てられないWindowsがいちばんUnicode移行を妨げてるんだが。
Re:意外と地味に改良が続いてていい (スコア:1)
いちばんUnicode移行を妨げてるのは、いつまでたってもShift_JISを捨てようとしない日本のユーザーの方じゃないかい？
やっとSVNに移行したのに (スコア:5, おもしろおかしい)
FreeBSDユーザですが、やっとソースツリーをCVS(csup)からSVNに移行したところなんで、まだ死ぬとかもう死ぬとかやめてよ。
Subversionは滅亡しない (スコア:5, 興味深い)
SubversionとGITは排他的なものでなく、場合により使い分けるものです。
Subversionはバージョン管理ツールですが
GITはソースコードパッチ管理ツールなのですよ。
GITを分散型の「バージョン管理ツール」と思うと混乱します。(私がそうでした)
Mercurialはどうかは知りません。
Re:Subversionは滅亡しない (スコア:1)
マージしないならsubversionの方がいいでしょうね。
Re: (スコア:0)
Gitでソースコード以外のものを管理してる俺は間違ってるのですね、わかりました。
# テキストとかdocとかxlsだよ。さすがに巨大なバイナリは放り込んでないよ。
Re:Subversionは滅亡しない (スコア:1)
とはいえSourceTreeを使う(これ) [cappee.net]なら、けっこう良いかもしれんね。
# とはいえ中央集権でブランチがコピーという分りやすさはそれでドキュメント系には嬉しいと思う(どっちも使う)
M-FalconSky (暑いか寒い)
Re: (スコア:0)
># テキストとかdocとかxlsだよ。さすがに巨大なバイナリは放り込んでないよ。
xlsってバイナリじゃね？
xlsxとかxml(Office 2003)とかならともかく
#ゲームとか画像系バイナリ扱うプロダクトだとgitでpushしたあと --depth 1でcloneしなおさないとDisk足りないっす orz
Re:Subversionは滅亡しない (スコア:1)
バザールでござーる (スコア:2)
Bazaar (bzr) のことも忘れないであげて(つд⊂)
屍体メモ [windy.cx]
Re:バザールでござーる (スコア:1)
それぞれ分散型のようにも中央集権型のようにも使えるのでござーる。
カレントディレクトリのbranch or checkoutを知るにはbzr info。
bind/unbindで切り替えることもできまする。
love && peace && free_software
t-nissie
Re: (スコア:0)
svnに慣れている状態からの移行先としては、一番とっつきやすいかもね
Subversionリポジトリと混ぜて使うこともできるし
gitよりSubversionの方が好み。 (スコア:1)
4人以下の少人数の開発だと、Subversionの方が手軽なんだよな。gitの機能を良く知らないだけだろ？ といわれると反論できんが。
Re:gitよりSubversionの方が好み。 (スコア:1)
CVSでできなかった空ディレクトリの追加がSubversionでできると喜んでたらgitでまたできなくなった。
gitkeepとか死ね。
Re: (スコア:0)
MAC使ってるデザイナーさんとかと一緒に仕事するときはSubversionですね。
Gitは(使い方を説明するのが)難しすぎる・・・
Re: (スコア:0)
gitの機能を良く知らないだけだろ？
Re: (スコア:0)
やめたげて
Re: (スコア:0)
gitはなぁ。GUIに決定打がない。
Re:gitよりSubversionの方が好み。 (スコア:2, おもしろおかしい)
GitHub for Windowsいいぞ
あまりにも糞すぎて結局Git Shell使ってコマンドで操作できるようになるところがもう最高
Re: (スコア:0)
うちなんかオレ１人 orz
Re: (スコア:0)
その上、ファイルも分けてないしブランチ切ったり手戻ったりしないのでCVSどころかRCSで十分だったり。
さすがにSCCSを実用で使ったことはない。
Re: (スコア:0)
TortoiseGITの完成度が上がっていて、TortoiseSVNと遜色なくなってきてますよ。
つい最近まで共用してましたが、違和感はほとんどありませんでした。
Git由来の機能を使うときは、操作感はちがってくるけど、これは仕方ないね。
Re: (スコア:0)
TortoiseSVNは使いやすいよね。
TortoiseGitはちょっと分かり辛くて説明し辛いし、並のプロジェクトではスケール過多な所がある。
ただIDEなんかが結構Gitに対応して来てて、機能が噛み合ってくると強力かも。
Re:gitよりSubversionの方が好み。 (スコア:1)
svnadmin でリポジトリ作って、svn で file:///path/to/repos にアクセスすれば良いので。
当然、/path/to/repos にアクセスできないとダメですが。
Re:gitよりSubversionの方が好み。 (スコア:1)
サーバくらい立てろよ、と思う。
Windowsだけど、CollabNet Subversion Edge をインストールすれば、全部入りSubversionサーバのできあがり。
Re:gitよりSubversionの方が好み。 (スコア:1)
お手軽さならVisualSVN Server [visualsvn.com]も負けてない。
とりあえずレベルの案件ならこれで必要十分です。
分散管理はロックができないから、集中型はなくならない (スコア:1)
バイナリーファイルとか、テキストでも GUI ビルダーや CASE ツールの出す XML ファイルは実質マージできない。
分散管理だけだとファイルのロックができないから、 Mercurial から Subversion のリポジトリーを指したり、 Git から TFS を指したりなどする必要があるので、
集中型自体がなくなって、全部分散管理ということにはならないと思う。
クロスプラットホームやフリーな点を考えると TFS だけになることもないので、 Subversion が消えることはないんじゃないかな。
Re:分散管理はロックができないから、集中型はなくならない (スコア:1)
何故にロックしなきゃダメなの？
どうせコンフリクト時は対応はケースバイケースだろうから、そもそも自動処理なんて期待出来ない。
ロックしたいってことは、同時に編集が入る可能性を前提にしているわけですが、中央集権型でロックされると作業にも不便をきたすのです。
また、中央集権型でロックなんてされた日には、ロックした奴が不在だとコミット出来なくなる問題が。
同じファイル弄りたい時点で事前に調整しておくような運用回避が必要なわけで、ロックなんてシステムの制約がないものを選ぶ奴のほうが多いのではないかと。
ロック出来るということはSVNの優位性にはならんということで。
最も私もSVN使いなのでそう簡単に無くなってほしくはないですけどね。
Gitは文字コード問題見てる限り、呆れて使う気になれません。
Windows/UNIXとまぜて使うと面倒じゃない？細工すりゃいいんだろうけど、そんなことしなきゃならんというのも。
それとも状況変わりました？ここしばらくはGitを見てないので私の知識は古いのかもしれません。
こちとら情弱なのでどうしても低きに流れてしまうのです・・・
しかし、中央集権型ソース管理 vs 分散型ソース管理 でなく、SVN vs Git の争いがばかりなのがなんとも。
Re:分散管理はロックができないから、集中型はなくならない (スコア:1)
どうせコンフリクト時は対応はケースバイケースだろうから、そもそも自動処理なんて期待出来ない。
編集していざコミットしようとしたらコンフリクトして編集やり直しって事態を避けるために、事前に手動でロックするのです。
中央集権型でロックなんてされた日には、ロックした奴が不在だとコミット出来なくなる問題が。
いざとなったらロックを奪うことができます。
同じファイル弄りたい時点で事前に調整しておくような運用回避が必要なわけで
それをシステム的にやるのがロックです。
ロックなんてシステムの制約がないものを選ぶ奴のほうが多いのではないかと。
ロックは必須ではなく任意です。やりたいチームがやりたいファイルだけやれば良いんです。
Re:分散管理はロックができないから、集中型はなくならない (スコア:2)
えっマジでまだいんの？
頑張ってくだされ
Re: (スコア:0)
バイナリーファイルとか、テキストでも GUI ビルダーや CASE ツールの出す XML ファイルは実質マージできない。
文字コードの問題の他に、この問題が大きいですね。
ドキュメントは、日本語ファイル名のMS WordとかExcelファイルとかマージできないものがほとんどなので。
移行することを考えるのが面倒なのでCVS (スコア:0)
うちの職場でLinuxのカーネルモジュール開発やってますが、相変わらずCVS。
さすがにすでに少数派なんですかね？
Re: (スコア:0)
分散型への移行を面倒くさがってる俺が言うのもなんだけど、CVS→Subversionの移行は無条件にやっちゃっていい／やるべきだと思う。
Subversionは良くも悪くもベターCVSなので、便利になることはあれ、基本不便になることはないイメージなので・・・。
（ブランチはちょっと考え方が違うけど。）
というか、CVSって文字コードとかフォルダの扱いとか、いろいろ面倒すぎね？二度と戻りたくないわ。
Officeなんかのドキュメント類もSubversionで管理したいけど (スコア:0)
コミットした日時じゃなくてファイルの更新日時を そろそろ保存できるようになりませんかねぇ。
Re: (スコア:0)
不特定多数で利用することを考えたら、合ってるかどうか分からないクライアントの時計で打たれたタイムスタンプなんか、なんの意味が
ブランチが使いにくい (スコア:0)
仕事で使っているけど、分散型に早く移行して欲しい。
開発中ブランチや実験ブランチを作って作業していたところ、管理者(上長)から「もっとキレイに使え」と、
実質、開発ブランチは作るな指令が出て困ってます。
Re:ブランチが使いにくい (スコア:4, おもしろおかしい)
(1) 開発機にも空の svn のリポジトリを作る。
(2) 職場の svn サーバのリポジトリを開発機のリポジトリに転送する。
(3) 開発機で好き放題にブランチを作って開発する。
(4) 職場の svn サーバのリポジトリには、うまく開発できたブランチから作った綺麗なパッチを反映させる。
(5) 便利になるように svn リポジトリ間の同期方法やパッチを綺麗にしたり管理したりするツールを作りまくる。
(6) git を再発明したことに気づく。
Re:ブランチが使いにくい (スコア:1)
それなんてsvk [bestpractical.com]
Re: (スコア:0)
中央リポジトリはSubversionのまま、ローカルで分散型を使うのがいいんじゃない？
他の分散型は知らんが、BazaarはSubversionリポジトリから直接ブランチを作成できたはず
Re: (スコア:0)
実験ブランチ等一時的に使うブランチはその中に作るようにしてるのを時々見かけるよ。
これならごちゃごちゃにならないで済むと思うけど。
# それすらも禁止されているというならご愁傷様
Re:ブランチが使いにくい (スコア:1)
バックアップの肥大化を嫌ってるんじゃない。
Re:ブランチが使いにくい (スコア:1)
ん？ブランチを作るのは変更をチェックインするためだろ。
作業用のブランチって言っているのだがら、タグ作る話じゃないだろ。
元コメの上司はそれが嫌なんじゃないかと推測しただけだが。
Re:ブランチが使いにくい (スコア:1)
わかってるわw
リポジトリに追加保存されるデータは修正に伴う差分だけ
って自分でもいってるだろうが。
作業用のブランチだからその差分は発生する。
当然作業量や作業する人の数によるだろうけど、肥大化はするでしょ。
つか、それぐらいしか考えられんじゃん、ブランチ禁止なんて。
Gitの意義 (スコア:0)
Git は Git そのものというより Github 的な……というか、Pull Request という文化が肝なんだと思ってます。
それが出来るからこその今の Git のブームがあると。
逆に、それを使わない Git というのは Git である必要があるのだろうか……とも。