公式HP
Apache Subversion
http://subversion.apache.org/
ようこそSubversion.JPコミュニティへ
http://www.subversion.jp/
Version Control Systems Comparison
http://better-scm.berlios.de/comparison/comparison.html
r13 http://toro.2ch.net/test/read.cgi/tech/1286654542/
r12 http://hibari.2ch.net/test/read.cgi/tech/1254838551/
r11 http://pc12.2ch.net/test/read.cgi/tech/1230488758/
r10 http://pc11.2ch.net/test/read.cgi/tech/1215565366/
r9 http://pc11.2ch.net/test/read.cgi/tech/1202086238/
r8 http://pc11.2ch.net/test/read.cgi/tech/1192864879/
r7 http://pc11.2ch.net/test/read.cgi/tech/1180858500/
06 http://pc11.2ch.net/test/read.cgi/tech/1165892754/
05 http://pc8.2ch.net/test/read.cgi/tech/1145841405/
04 http://pc8.2ch.net/test/read.cgi/tech/1129642894/
03 http://pc8.2ch.net/test/read.cgi/linux/1100622362/
02 http://pc5.2ch.net/test/read.cgi/linux/1078609142/
01 http://pc.2ch.net/test/read.cgi/linux/1002355536/
http://tortoisesvn.net/
■文書
Subversionによるバージョン管理(日本語訳)
http://subversion.bluegate.org/
svnbook PDF版
http://psyto.s26.xrea.com/misc/svnbook/
CVSユーザのためのSubversionガイド(wakatonoさん)
http://slashdot.jp/journal.pl?op=display&uid=12&id=200792
■Wiki
Subversionメモ
http://terai.xrea.jp/Subversion.html
■記事(ちょいと旧め)
http://www.atmarkit.co.jp/flinux/special/webdav/webdav03c.html
http://www.atmarkit.co.jp/flinux/special/webdav03/webdav02a.html
http://ukai.jp/Slides/2003/0521-lw2003/html/
http://ukai.jp/Articles/2003/uu-svn/
バージョン管理システムについて語るスレ8 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1295493964/l50
CVS 1.3 [UNIX板]
http://hibari.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://engawa.2ch.net/test/read.cgi/linux/1154701996/
Git 3 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1310403238/
【分散型バージョン管理】 Mercurial 2【hg】 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 2 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
Gitとかに比べれば時代遅れかもしれないけど、
まだまだ Subversion を使う現場は多いので、仕切り直していきましょう。
今では見向きもされないのが不憫でならない
1000 git
確かに何追加されたか知らない……
git/hgは高機能で便利だけどそれは複雑さとのトレードオフでもあるからね。
会社で使おうとしてもまだ平均的プログラマが使いこなせるものではないと思う。
レベル低いって言われたらまぁそうなんだけど。
checkout,commit,updateだけでほとんど済んでしまうsvnのシンプルさは素晴らしい
>checkout,commit,updateだけでほとんど済んでしまうsvnのシンプルさは素晴らしい
それはgit/hgでも同じこと
> 会社で使おうとしてもまだ平均的プログラマが使いこなせるものではないと思う。
git/hgはコマンドラインは枯れていて、GUIも充実してきているから、
今使い始めなければ、永久に使いこなすことはできないだろう。
禿しく同意だわ
自分も理解しきれてないのもあるけど、音頭取りの立場としては
考え方がちょい(？)複雑になる分散システムを、皆が普通に使えるか不安。
日本語ファイル名のものもあるから、文字化けせずに安心して使えるか？ とか
>>14
そうなんだよな〜 焦るぜ。
変えるなら、まだまだ規模の小さいうちに・・・ とか思うんだけどね。
わざわざ新しい物に食いつくにはそれなりの理由があると思うけど、
その理由は何？
ともあれ他のものを食べてみないことにはそれが今のものよりもうまいのかまずいのか実感できないよ
みんなは出来てる？
TortoiseSVN 1.7.4 Win7(x64)
オフラインでも使えると便利
サンキュ
やっぱりみんなは出来てるんだな
確か1.7から出来なくなった気がする
環境の問題か
フォルダを右ドラッグすると「SVNバージョン管理下の項目をここにエクスポートする」
だけが表示されて、
ファイルを右ドラッグしたときはSVN関係のメニューは何も表示されない
XPの32bitではちゃんと出来てるけど、Win7の64bitはダメなのか？
誰か助けて
それ、バージョン管理下にあるファイルやフォルダを右ドラッグして、
バージョン管理下にないフォルダにドロップしようとしてないか？
>>16
> わざわざ新しい物に食いつくにはそれなりの理由があると思うけど、
> その理由は何？
sourceforge.net を「開発者」として利用すればわかる。1にスピード、2にスピード。
サーバーの問題もあるんだろうがsvnだと履歴見たりコミットするのに数分かかることがあるんだよね。全く使い物にならない。
gitはローカルしか参照しないから一瞬。回線が弱いところで分散型は強い。
ブランチガーとかマージガーというのはこれに比べたら些細な理由。もちろん便利なことは否定しない。
会社でsvn使っていても、積極的にgitに変えたいと思うほどの不満は感じない。
「OSSが次々とgitに移行」というのはgitの勢いを表してはいるけど、
OSS特有の事情を含んでいることも知った上で考えないと
回線スピード関係ないじゃん。
ギガのデータを数分で取得するのは当たり前の環境だけど、常時接続とは限らない。
GITサーバーってそんなに性能高いのか?
やっぱり、バカ専用。ｗｗ
> GITサーバーってそんなに性能高いのか?
GITにサーバーなんてないけど？
しったかぶりの幼稚園児乙
やっぱり、バカ専用。ｗｗ
> ギガリポジトリを数分で取得するには20Mビット/s程度で転送する必要があるんだが、
コマンドラインでgit cloneを叩けば、転送速度も表示されてこれ位余裕で出るのはすぐわかるのだが。
いいかげんsvnスレをゴミで埋めるのやめたら？
他の健全なsvnユーザに迷惑だよ。
> 要求する方がクライアント、要求にこたえる方がサーバ。
gitでは一貫して「リモート」と呼んでいる。
リモートでの作業
http://progit.org/book/ja/ch2-5.html
どっちがウソつきなのでしょう? ｗ
http://www.ibm.com/developerworks/jp/linux/library/l-git/
Git が kernel.org からローカル・マシンにカーネル・ソース (サイズは何百メガバイトにもなります) を転送するため、このステップは長時間かかります。
出力はかなり見にくく、インターネット接続が高速な場合は、相当早くスクロールするはずです。出力は図 1 のようになります。
日付: 2006年 7月 06日 (公開: 2006年 6月 29日)
Cloning into linux...
remote: Counting objects: 2330153, done.
remote: Compressing objects: 100% (480501/480501), done.
remote: Total 2330153 (delta 1912008), reused 2238807 (delta 1827162)
Receiving objects: 100% (2330153/2330153), 546.78 MiB | 1.39 MiB/s, done.
Resolving deltas: 100% (1912008/1912008), done.
real 12m6.126s
user 4m1.950s
sys 0m44.356s
Cloning into linux...
remote: Counting objects: 2330153, done.
remote: Compressing objects: 100% (395655/395655), done.
Receiving objects: 100% (2330153/2330153), 546.78 MiB | 6.97 MiB/s, done.
remote: Total 2330153 (delta 1912008), reused 2330153 (delta 1912008)
Resolving deltas: 100% (1912008/1912008), done.
real 6m40.600s
user 3m57.155s
sys 0m36.466s
> real 12m6.126s
やっぱ数分はウソじゃん。
> 546.78 MiB
> だからLinuxのカーネルのソースは何G？ (ｷﾘｯ
これもウソだし。
#############
#################
### ##
# #
# #
# #
## ##
######### ####
######
# #
#####################
#####################
# #
####
###
#
# #
#####################
#####################
# #
#
###
####
原因が分かった
エクスプローラに /root オプションをつけて起動したフォルダ以下では
右ドラッグが効かないようだ
俺はいつもプロジェクト毎で /root をつけてエクスプローラを起動して
るからこのおかげで全然出来なくなってた
.svnフォルダがなくなってることには気づかなかったの？
開発プロジェクト全体のフォルダって事ね
svnの作業フォルダは当然そのプロジェクトフォルダの下にある
年明けからWin7に変更したんだけど、こういう微妙な互換性問題はあるね
さっきから更新しようとしてるんだけど、やれtoo largeだのconnection closedだのsvndiffデータの解凍に失敗だの
クリーンアップしてやりなおしの繰り返しで少しずつ落ちてきてるが、やってられるか
駄目だコリャ
1日かかった…
TortoiseSVNか、subversionのせいだよ
こういうときはまず自分を疑うのが有能なエンジニア。
原因は多分プロジェクトのサイズがでかすぎることか、鯖がそれに対して非力なこと
プロジェクトのサイズがでかいといっても要因はいろいろだよね。
revision数がすごいとか、馬鹿でかいファイルをcommitしたとか。
プロジェクト（コミットされてるファイル一式） 350MB ファイル数50712 フォルダ数841
svnバージョン 1.4.2 (r22196)
TortoiseSVN 1.7.4 Win7 Pro 32bit Phenom II X4 955 3.20GHz 4GB
サイズは案外大したことなかった、中身はPHPのフレームワークで作ったWebサービス一式
ただ画像などバイナリファイルが多い
現在9000ぐらいです
同じ鯖で同じPCで別プロジェクト（リポジトリ同じ、ファイル数少ない）だと大丈夫ぽい
同じ鯖で別PCで問題のプロジェクトだと問題発生
なのでこのプロジェクト固有の問題と見てよさそう
問題が起きない方のプロジェクトもリビジョンは同じくらい
となるとsubversionは、ファイル数が万の桁ぐらいになると実質使えなくなるということだろうか
find . -print | wc -l => 約12,000
du project_dir => 約190MB
で、svn stは一瞬、svn updateが3秒位。
鯖のスペック。メモリは1GB。
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Celeron(R) CPU 2.40GHz
stepping : 1
ファイル数が多いとチェックアウトやアップデートが途中で終わるというのはよく経験したよ。
TortoiseSVNよりsvnコマンドを使う方が改善はするけど結局問題は起きます。
あとリビジョンが増えるとsvn logが時間かかりすぎるのでオプションで範囲を絞った方がよさげ。
今までsubversionしか使ったことないからわからない
svnからの切り替え先にbzrを検討するなど（最終的にはhgになった‥）
http://togetter.com/li/91517
> 鯖 CentOS5.4 XeonE5620@2.40GHz 4GB ただしクラウド上の仮想、他のサービスはOK（重くない）
クラウド上ってのが気になるな。ネットワークが不安定なんじゃないの？
「他のサービスは重くない」のは具体的になに？
svnほど短時間に大量のデータをやりとりするもの？
ネットワーク的に近いVMの上に最新バージョン入れて速ければネットワークが原因だろうな。
過去ログにも散々でてるけど回線が細くて不安定だとsvnはつらい。
> プロジェクト（コミットされてるファイル一式） 350MB ファイル数50712 フォルダ数841
リポジトリサイズは大きくないと思う。
ファイル数 2-4万、3-7万リビジョン、ファイル数 1-4万程度のリポジトリがいくつかあるけどエラーなんて起こったことない。
svn updateはせいぜい数十秒。ただほとんどがソースファイルでサーバー(v1.5.xか1.6.x)は社内にある。
ネットワークは問題ないと思う、SVN以外で不具合を感じたことはない。
開発用サーバーなので、本番用と同じWebサービスが一式入っている。
ApacheとMySQLとmemcachedとTokyoTyrantを使用。SVN以外にWinSCPでファイル一式上げたりもするが、そっちは問題なし。
そんな感じで絞っていくと、結局画像ファイル数が多いことぐらいしか思い付かない。
SVNってバイナリ苦手なんだっけ？
画像が大量追加された時によく問題起きてる気がする。画像1個1個は小さいんだけど。
> 開発用サーバーなので、本番用と同じWebサービスが一式入っている。
開発サーバーとリポジトリサーバーが同じなのか？本当にいいのかそれでw
> ApacheとMySQLとmemcachedとTokyoTyrantを使用。SVN以外にWinSCPでファイル一式上げたりもするが、そっちは問題なし。
これらは開発PCとの間で大量データをやり取りするわけじゃないよな。
> 具体的に調べたら、画像が200MBぐらい、ファイル数32000ぐらいだった
通信のときにバイナリとテキストなんか区別してないから、この程度で問題が起きるとも思えない。
まだネットワークが問題という疑念は捨てきれないが、そうでないとしたら、、
> svnバージョン 1.4.2 (r22196)
これがはずれバージョンなのかもしれない。別サーバーで1.6か1.7を試してみたら？
クライアントの話だけどリリース前の1.7.0-Beta(Serfを採用していたバージョン)は
通信が不安定でcheckout中に頻繁に落ちてた。(1.7リリースでは最終的にNeonになって安定した)
http://svn.apache.org/repos/asf/
現時点で124万リビジョン
kwsk
kwsk
http://svn.haxx.se/dev/archive-2012-02/0392.shtml
bzrはあれがスレの主ですから
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=755&dsMessageId=2922121
要領削減のため実態のコピーは行われないと思います。
ファイル名がA〜Zまでの巨大なバイナリファイルがあって
それらをほとんど結合したようなファイルAAに統合したいのですが
コピーと同じように、実態のコピーではなく、
結合の関係だけをリポジトリに記録することはできないでしょうか。
残念ながら今はそういう記録の仕方はできないね。
AAを作るスクリプトを作っとけばいいかもしれない
http://sourceforge.jp/magazine/12/02/15/1149213
「A new version of TortoiseSVN is available〜」が出るんだけど、
この文字を消す設定はありますか？
バージョンアップはこっちの都合のいいタイミングで行うので、
毎回せかされたくないんですが。
ヘルプ嫁
#############
#################
### ##
# #
# #
# #
## ##
######### ####
######
# #
#####################
#####################
# #
####
###
#
# #
#####################
#####################
# #
#
###
####
#####
#############
#################
### ##
# #
# #
# #
## ##
######### ####
######
# #
#####################
#####################
# #
####
###
#
# #
#####################
#####################
# #
#
###
####
#####
#############
#################
### ##
# #
# #
# #
## ##
######### ####
######
# #
#####################
#####################
# #
####
###
#
# #
#####################
#####################
# #
#
###
####
別マシンの共有フォルダ上にリポジトリフォルダを置いているのですが、
そこをエクスプローラのコンテキストメニューからリポジトリブラウザで開くと、
file://…/Hoge
├Hoge
│├brunches
│├tags
│└trunk
├brunches
├tags
└trunk
という変なツリー構造で表示されてしまいます。
「URL」に記述されているマシン名をすべて小文字にすると、
file://…/Hoge
├brunches
├tags
└trunk
と正しく表示されます。
1.6のときは発生していなかったのですが、
1.7では表記の違いで表示が変わるようになってしまったのでしょうか？
>
> 原理上、 FSFS リポジトリはネットワークフォルダー上に配置でき、 file:// プロトコルを用いて
> 複数のユーザーからアクセスできますが、これは絶対にお勧め しません 。実際のところ、この
> ような使い方を私たちは思いとどまってほしいと 強く 思いますし、サポートもしません。
複数人ではアクセスしてないです。
してんだから、それはそういうものだとして我慢しとけ
さらば SVN
これでちゃんと特徴を見てVCS選択できるようになるな。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
Visual Studio 2012 Part4 (431)
ARToolKitでARを作ろう (245)
リファクタリングをただのコード修正と思ってる人へ (274)
【入門】Common Lisp その9【質問よろず】 (630)
関数型言語ML (SML, OCaml, etc.), Part 6 (574)
なぜポインタで引っかかる人が多いのか (803)
--log9.info------------------
【アコギ】アコースティックギター総合スレ♪４ (974)
【アンプ】JC-120 part7【トランジスタ】 (447)
Fender Telecaster Part50 (304)
hideの音ーPart4 (598)
Gibson Melody Maker メロディメーカー (217)
ギター知らない奴が適当に話しを合わせるスレ5 (266)
【喧嘩】ビンテージギター所有者のスレ【上等】 (348)
ごちゃごちゃ言わずにワウ（WAH）を踏め！11 (777)
転売専門 下北 ロクソボーイズ (631)
ジェフ・ベック Jeff Beck Part30 (518)
【エフェクター】ブースター 10dB【アンプ】 (931)
【言い訳】八幡謙介について語る５【駄演】 (275)
【Fender】フェンダーアンプ 25発目【AMP】 (490)
ケーブル・ピックアップは単なる思い込みにすぎない (779)
防音室・自宅スタジオ総合 (843)
【Relic】塗装､外見総合ｽﾚ part11【ペイント】 (367)
--log55.com------------------
【悲報】帰宅途中に自販機でお茶を買った生徒、反省文を書かされる
【悲報】世界に広がりつつあるシノフォビア（中国嫌悪）
ジャーナリスト「ウソがはびこる政権を、誰が支持するのか」
隠れ貧乳の見分け方
misono「夫の給料が少ない。全額私がだしている。子作りにも入りたいのに出来ない」
【映画】是枝監督、カンヌ最高賞で日本政府からの今さらな祝意を辞退。ネトウヨ怒りの万引き家族へ
東洋経済「Googleが"JSON"という気味の悪い拡張子を使っている」 → 英語原文と乖離、謝罪
足利義満「屏風のトラを捕まえてくれ」一休「ではトラを屏風から追い出して下さい」
