Subversion r14

1 名前：デフォルトの名無しさん [2012/01/17(火) 22:27:39.03 ] Subversionはフリーなオープンソースのバージョン管理システムです。 公式HP Apache Subversion subversion.apache.org/ ようこそSubversion.JPコミュニティへ www.subversion.jp/ Version Control Systems Comparison better-scm.berlios.de/comparison/comparison.html 111 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 13:49:21.46 ] >>110 git-svnでGit Extensions msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ d.hatena.ne.jp/nitoyon/20120221/msysgit_utf8 112 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 13:59:05.44 ] >>111 Git信者ってなんでこんなに必死なんだ? 113 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 14:05:14.44 ] >>110 TortoiseSVNの影響でエクスプローラーが重いのなら、 アイコンオーバーレイの「状態のキャッシュ」を無しにしてみたらどーだろ 114 名前：デフォルトの名無しさん [2012/02/22(水) 14:11:42.34 ] >>112 svn信者ってなんでこんなに必死なんだ? 115 名前：110 mailto:sage [2012/02/22(水) 15:13:54.48 ] >>113 レスありがとうございます。 それもためしてみたのですが、 ・アイコンオーバーレイ無： 　フォルダにはマークがつくが、ファイルにはマークがつかないのでわかりづらい。 ・アイコンオーバーレイシェル： 　再帰的にマークを付けなくなるので、サブフォルダでは変更中(赤)のものがあっても、 　親フォルダに戻ると、そのフォルダ名は赤でなく緑で表示されるので、勘違い(作業ミス)の元になる ということでいまいちです。 まぁエクスプローラが遅いのに加え、TSVNcache.exe がバックグラウンドでずーっとガリガリ行っているのも 原因だと思うのですが、このあたり WinCVS は、うまく操作性とバランスが両立していました。 なのでそういった独立したGUIツールを探しています。 116 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 16:18:56.23 ] >>115 bzr-svnでBzrExplorer 117 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 22:02:22.79 ] >>115 RapidSVNの完成度が低いのが痛いな。 気休めだがTortoiseSVNを最新にしてみたら？ 各フォルダの.svnも無いし、1.7は相当良くなっているよ。 118 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 22:43:13.92 ] >>104 > file:// アクセスは、ローカルでの1ユーザーのみのアクセスを想定しており、そのようにテストとデバッグを行っています。 これも含めて引用しないと、推奨されない(およびそれが非サポートである)根拠にならないってことだよ。 たとえば以下のようなレスを初心者に対して行うとどう捉えるだろうか。 svnのマニュアルより引用 > 複数のユーザーからアクセスできますが、これは絶対にお勧め しません 。 > 実際のところ、このような使い方を私たちは思いとどまってほしいと 強く 思いますし、サポートもしません。 119 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 22:44:43.98 ] 連レスになるけど。 >>109 引用が不適切だったから、そのどちらとも取れるレスになっていたよね。 120 名前：デフォルトの名無しさん mailto:sage [2012/02/22(水) 23:02:22.42 ] smartSVNっていうのはどうか もし試したら使用感をおしえてくれ 121 名前：110 mailto:sage [2012/02/23(木) 01:56:28.08 ] みなさんレスどうもありがとうございます。 >>117 それもちょっと考えた。職場の人が TortoiseSVN 1.7 にしたら だいぶ早くなったといっていたので、入れ替えてみるか。 作業コピーのディレクトリは、checkoutしなおしだな。 >>120 あれから subversion gui client などでググってみましたが、 いろいろあるようですね。 Comparison of Subversion clients - Wikipedia en.wikipedia.org/wiki/Comparison_of_Subversion_clients Subversionのクライアント: MyWay volatile.cocolog-nifty.com/blog/2007/03/subversion_e769.html SmartSVNはさっきおとしてみたので、あとで使ってみる。 122 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 03:23:19.57 ] >>92 > という変なツリー構造で表示されてしまいます。 1.7.x Repo Browser - showing folders twice tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2922366 このバグが近いんじゃないか。 Nightly Build(TortoiseSVN-1.7.99.22573-dev-x64-svn-1.7.x-dev.msi) で試したら直ってた。（大文字でアクセスできなくなっていた） nightlybuilds.tortoisesvn.net/latest/ 123 名前：92 mailto:sage [2012/02/23(木) 09:15:26.87 ] みなさんありがとうございます。 >>122の情報だと、近々直りそうな感じなので、 とりあえずこのまま次のバージョンを待とうかと思います。 124 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 09:21:57.77 ] 共有フォルダにリポジトリをおいて file:/// プロトコルが推奨されないのは 複数同時アクセスに比較的弱いのと、権限上、誰でもファイルを消せてしまう（リポジトリを壊せてしまう）からだよ。 ネットワーク経由であることになにか致命的な欠陥があるわけじゃない 125 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 11:00:45.43 ] >>118-119 最初に引用したときは、一人で使ってるなんてわからなかったんだよ 126 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 11:51:42.47 ] >>124 議論を蒸し返すようで申し訳ないけど、 権限上誰でも壊せてしまうのは、運用でどうにでもなるからいいとして、 同時アクセスについては、速度はともかく、FSFS だったら一貫性は 保たれているのかな、と思っていた。 127 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 15:28:44.99 ] >>117 >各フォルダの.svnも無いし、 あれ？そうだっけ？と思い確認してみたら .svnはルートだけになってたわ。 気づかなかった…（ぉぃｗ 128 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 15:36:06.03 ] >>125 あたまわるい 129 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 16:21:03.57 ] >>127 Subversion 1.7からそうなったんだよ 130 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 22:17:36.29 ] >>125 >>128みたいにあたまわるいとは言わないが、複数人で使うかどうかは関係なかったんじゃないか？ 131 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 13:25:47.47 ] >>126 リモートファイルシステムの動作保証 まではできないだろ。 ふさふさをどうこういっても、所詮は ファイルベースなんだし。 132 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 14:40:00.02 ] >>131 お前、頭悪いぞ。 境界はFSFSが要求する排他制御のメカニズムという事で動作保証は可能。 つーか、file:スキームで直接アクセスするクライアントもhttp:,svn:(ssh+svn:) も同じメカニズム使ってるので、動作保証してくれてなけりゃ使えない。 133 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 14:57:29.81 ] ん？ クライアントなんか関係無くて、問題はsvnのサーバあるいはコマンドだろ。 134 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 15:01:21.23 ] >>132 お前、頭悪いぞ。 > file:// アクセスは、ローカルでの1ユーザーのみのアクセスを想定しており、そのようにテストとデバッグを行っています。 と明言されてるのがわからんの？ 135 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 15:06:13.52 ] >>132 ロックはディレクトリにファイルを作って消す。 ディレクトリのパーミッションがWindowsとUnix/Linuxでは違う。 ディレクトリにファイルを追加できるが削除できないとか。 中間ファイルがゴミの山。 136 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 15:34:27.54 ] >>133 > クライアントなんか関係無くて、問題はsvnのサーバあるいはコマンドだろ。 そのsvnのサーバあるいはコマンドも同じメカニズムを使って排他制御している。 svn: svn+sshならsvnserveだ。こいつらはクライアント毎に別プロセスが排他制御 してFSFSにアクセスする。 >>134 バカ? アクセススキームに関してのテストをそれしかやってないと言ってるだけだ。 FSFSの排他制御とは独立。 >>135 お前がこの三バカのなかで、一番頭悪そうだ。ドキュメント読めよ。 Note: Locking ------------- Locking is currently implemented using the apr_file_lock() function, which on Unix uses fcntl() locking, and on Windows uses LockFile(). Modern remote filesystem implementations should support these operations, but may not do so perfectly, and NFSv2 servers may not support them at all. 137 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 15:37:59.86 ] >>136 ご託はいいから、一人がアクセスする場合に限れば、あらゆるファイル共有プロトコルをsvnが正式にサポートしている証拠を示せ。 138 名前：デフォルトの名無しさん [2012/02/24(金) 15:46:19.40 ] >>136 その引用にもperfectlyでないと書いてあるが？ 139 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 15:57:02.51 ] >>122-123で終わった話題をいつまでやってるんだろう、この人達 140 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 15:58:53.55 ] 　　　　　　　##### 　　　　############# 　　 ################# 　###　 　 　　　　　　　　## 　#　 　 　 　 　 　 　　　　　# #　 　 　 　 　　　　　　　　　# 　#　 　 　 　 　 　 　　　　　# 　##　 　 　 　　　　　　　## 　　#########　　　　 #### 　　　###### #　 　 　 　 　　　　　　　　# ##################### ##################### #　 　 　 　 　　　　　　　　# 　　　　　　　　　　　　 #### 　　　　　　　　　　　　　### 　 　 　 　 　 　 　 　 　 　 # #　 　 　 　 　　　　　　　　# ##################### ##################### #　 　 　 　 　　　　　　　　# 　 　 　 　 　 　 　 　 　 　 # 　　　　　　　　　　　　　### 　　　　　　　　　　　　 #### 141 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 16:19:47.17 ] >>137 そんな事誰がいつ言ったんだ? 糖質は周りがすべて敵に見えて妄想に入り込むらしいな。 基地外病院行った方がいいぞ。 >>138 apr_file_lockで排他制御してる、unixだったらfcntl, WindowsはLockFile, でもそれがうまく動かんときは知らんもんね。という意味。 その範囲で保証してくれりゃ十分だよ。それで足りないというならお前が自分で検証する事だ。 >>139 こんなところで粘着してる余裕はないぞ。Git信者。 Mercurial vs Git: Why Mercurial? blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ 142 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 16:31:27.77 ] >>141 > その範囲で保証してくれりゃ十分だよ。 その範囲でしかsvnを使ったことが無いのがよくわかった。つまり一人だけで。 143 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 16:36:02.33 ] >>141 お前が一番粘着質 消えろ 144 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 16:44:18.81 ] >>141 お前が何の話をしたいのか知らないが、お前以外は、たとえ一人でもFSFS・ファイル共有で使うのは良くない、 またはサポートされていないという話をしている。 で、お前は > 動作保証してくれてなけりゃ使えない と言うが、そもそもそんな動作保証やサポートされてませんがという話。 145 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 16:52:49.33 ] >>141 周りが全て敵に見えてるのは、君の方では？ 146 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:23:53.80 ] >>143 糖質は早く基地外病院行った方がいいって。 >>144 > お前が何の話をしたいのか知らないが、お前以外は、たとえ一人でもFSFS・ファイル共有で使うのは良くない、 それはお前が頭が悪いからそのようにしか理解できてないだけ。 俺が言っているのは、リポジトリにアクセスするのがsvnであろうとsvnserveで あろうとはたまたmod_svnであろうと、同一の排他メカニズムを使用していて、 信頼性は同一。 共有フォルダでのfileスキームでのアクセスが非推奨なのはアクセス制御が できないから。これが技術的問題。これを指摘しただけだ。 一人ならFSFS・ファイル共有で使ってよいかという問題は、前述のように排他制御 という観点からはなんら問題ない。 147 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:43:01.81 ] なんとなく >>141=146 が言っていることもわかる。 svn の中身で、ファイルの排他制御をやっている個所は、 Unix版なら fcntl、Windows版なら LockFile の API を呼んでいるだけで、 それを使った結果どうなるかは、これらの API 依存であり、subversion は関知しない。 Unix の fcntl は、Windows の LockFile に比べて優秀なだけ、ということかな。 >>146 へ： > 一人ならFSFS・ファイル共有で使ってよいかという問題は、前述のように排他制御 > という観点からはなんら問題ない。 たぶんこれはみんなもわかっていて、複数人で同時アクセスで FSFS・ファイル共有したときに、 アクセス制御は除外したとしても、DB が壊れるかどうかをみんな議論しているんだと思うよ。 148 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:43:56.53 ] WindowsのSMBもSambaもNFSも同一の排他メカニズムを使用していて、ファイル共有プロトコルより 上位のアプリケーションレイヤーから見れば信頼性は同一？ んな馬鹿な。 149 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:48:51.88 ] >>147 > DB が壊れるかどうかをみんな議論しているんだと思うよ。 少なくとも俺はしてない。 FSFSでファイル共有を使ったfile:スキームのアクセスの動作保証がされてるかどうかが論点。 >>146 > 一人ならFSFS・ファイル共有で使ってよいかという問題は、前述のように排他制御 > という観点からはなんら問題ない。 そもそもそんな動作保証はされてませんが。 コード全部読んで、どんなファイル共有プロトコルでも問題ないことでも確認したのか？ 150 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:55:55.66 ] これ読むと、一人で使う場合でも、ファイル共有でも動作保証はされてないと思うけど。 tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-repository.html#tsvn-repository-local-share まぁ、普通に使ってれば、そうそう問題ないんだろうけど。 ここに書かれてない問題として、ファイルの大文字小文字問題もある気がする。 151 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:56:04.05 ] >>147 > たぶんこれはみんなもわかっていて、複数人で同時アクセスで FSFS・ファイル共有したときに、 > アクセス制御は除外したとしても、DB が壊れるかどうかをみんな議論しているんだと思うよ。 だから、同じファイルシステムを使う限り、fileスキームで同時アクセスと svn, ssh+svn, httpスキームでの同時アクセスの信頼性は全く同一。 むしろ、同一メカニズムを使ってるのにあっちはダメでこっちはOKと考える 根拠を聞きたいわ。 >>148 > んな馬鹿な。 そう、あなたがバカなのです。だれもそんなことは言っていない。 >>149 > FSFSでファイル共有を使ったfile:スキームのアクセスの動作保証がされてるかどうかが論点。 コード見れば。おバカさん。 152 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 17:59:26.45 ] >>151 > 同じファイルシステムを使う限り どんどん、妄想が膨らんでるようです。 > むしろ、同一メカニズムを使ってるのにあっちはダメでこっちはOKと考える > 根拠を聞きたいわ。 同一メカニズムじゃありませんから。 ネットワークレイヤーを絡めて、同一かどうか説明してみな。 153 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 18:02:30.19 ] >>150 >>151のリンク先で、Sambaを使うと困難と書かれてるけど。（困難だが全て問題を解決してるのかもしれないけど） ローカルとリモートじゃ何か違うんじゃない？ 154 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 18:12:11.82 ] >>152 コード読めないバカですか。参加資格ないのに吠えてるのは惨めだから退場しなよ。 svnがfileスキームで直接リポジトリにアクセスする場合も、svnserveがクライアン トからの要求受けてリポジトリにアクセスする場合もlibsvn_reposが提供している、 同一のAPI使ってるんだよ。 155 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 18:19:49.84 ] >>154 その同一のAPIが実行される場所が違うんですが。 ところで、最近はやりのNドライブや、今あるかどうか知らないけど、GMailをドライブとしてマウントできるドライバとかが あったけど、これらもやっぱりマウントできてしまえば、信頼性は同じなんすかね。 156 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 18:25:30.53 ] >>155 バカですねえ。周回遅れですねえ。知恵遅れですねえ。死んだ方がいいですねえ。 そんな比較してるのはバカで周回遅れで知恵遅れのお前だけだから。 157 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 18:26:26.80 ] >>156 今まで全く想定もしてなかったところをズバリ突かれて、壊れたようです。 158 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 18:47:31.11 ] >>157 知恵遅れのお前は周回遅れを自覚してないから平気なんだろうけど、はたからみると惨めすぎるぞ。ｗｗ バカが入り乱れててわかりにくいけどお前、>>149だろ。 >>155を問題にしているなら >>149 > FSFSでファイル共有を使ったfile:スキームのアクセスの動作保証がされてるかどうかが論点。 じゃなくて、リポジトリ(FSFS)をリモートファイルシステムの置くことの是非が論点。 そして、開発元はそれをできると言っている。 159 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 19:02:32.85 ] sambaもNFSも、細かいところでは あんまり信頼するべきではないはず。 最近はずいぶんマシなんだろうと 思うけど。 >>158 ＞リポジトリ(FSFS)をリモートファイルシステムの置くことの是非が論点。 えっ？ 動作保証されてなければ是非もクソも ねえよ。 160 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 19:10:30.32 ] >>159 周回遅れに気づいても平気なのか。知恵遅れはある意味最強だな。 普通の知能なら恥ずかしくて100回は首つってるぞ。 > 動作保証されてなければ是非もクソも 開発元はFSFSはリモートファイルシステムにおけると言っている。 これで不十分なら商用システム使ってろ。 161 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 20:41:31.35 ] スレ進みすぎわろた。前スレの終わりよりぜんぜんましだけど。 >>158 > > FSFSでファイル共有を使ったfile:スキームのアクセスの動作保証がされてるかどうかが論点。 > じゃなくて、リポジトリ(FSFS)をリモートファイルシステムの置くことの是非が論点。 もともと(>>92)はfile://でアクセスしたときの話だったよ。 で、>>93が不十分な引用をしたので>>118を書いた。 > じゃなくて、リポジトリ(FSFS)をリモートファイルシステムの置くことの是非が論点。 という話になったのってどっから？ 162 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 22:03:46.16 ] >>161 > もともと(>>92)はfile://でアクセスしたときの話だったよ。 周回遅れの知恵遅れの>>159がついてこれてないだけで、それは既に結論が出ている。 アクセス制御ができない事が非推奨の理由 > > じゃなくて、リポジトリ(FSFS)をリモートファイルシステムの置くことの是非が論点。 > という話になったのってどっから？ >>131だな。開発元が置けると言っているのに、動作保証が…と言い出した。 バカが入り乱れてわかりにくいけど、動作保証にこだわっているから、 >>131は最後まで分からなかった周回遅れの知恵遅れ(>>159)だろう。 163 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 22:16:25.00 ] >>162 >>118で言及したように、どうとでも取れるレスをあえて曲解しているだけなら止めはしないよ。 164 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 22:36:22.47 ] >>162 知恵遅れなりに恥ずかしいと思って必死に考えたのか? でも、やっぱり知恵遅れの浅知恵な反論。ｗｗ >>131で頓珍漢な言いがかりをつけた>>126は「権限」に関しては除外しているので、 FSFSの排他制御に関する議論だ。 まあ、バカだからわからなかったんだろうけど。バカってかわいそう。 165 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 22:40:00.34 ] >>160 周回遅れに気づいても平気なのか。知恵遅れはある意味最強だな。 普通の知能なら恥ずかしくて100回は首つってるぞ。 >開発元はFSFSはリモートファイルシステムにおけると言っている。 ソース出せ。 ソースコードのapr_file_lockうんぬんはどうでもいいから。 166 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 22:45:26.67 ] >>165 惨めだからもう止めなよ。自覚のない知恵遅れって本当にかわいそう。 svn.apache.org/repos/asf/subversion/trunk/notes/fsfs * Can host on network filesystem FSFS repositories can be hosted on network filesystems, just as CVS repositories can. (See "Note: Locking" for caveats about write-locking.) 167 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 23:27:58.57 ] >>165 ソース出てきた時の事は全然考えなかったのか? 知恵遅れ憐れすぎる。 168 名前：デフォルトの名無しさん mailto:sage [2012/02/24(金) 23:31:14.77 ] >>165はまだfile://の話をしているのかもしれない 169 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 00:30:01.46 ] 今日は静かだな。>>165は息してるか? 170 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 08:54:57.09 ] マージした後ヒストリーみるとMってなってるけどマージ元がどこかはわからない？ コピーみたいに元がわかると嬉しいんだけど 171 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 09:14:43.49 ] svn propget svn:mergeinfoじゃ不足? これ以上の情報は残してない。 >>165 またいじめてやるから出てこいよ。 172 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 09:30:57.84 ] >>171 Subclipseのリビジョングラフとかでもマージの矢印はないし svn mergeinfoしても何も表示されないんだ 173 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 10:02:12.64 ] >172 svn mergeinfoの使い方間違ってない? svn mergeinfoはマージ元指定する必要があって、指定してやれば表示されるけど。 174 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 14:52:46.75 ] TortoiseSVNだとShow logのInclude merged revisionsでマージ元での変更見れるけどそういうことではない？ 175 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 15:38:38.07 ] あざーす。でもInclude merged revisionsだと細かすぎて見辛いお。。。 copyだと詳細欄にコピー元がずばり書かれてるけどそんなかんじではみれへんのですか。 176 名前：デフォルトの名無しさん mailto:sage [2012/02/26(日) 23:20:12.28 ] 仕組み上それはできないんじゃないか。 コミットログに「branches/XXX をマージ」って書いといたら？ 177 名前：デフォルトの名無しさん mailto:sage [2012/02/27(月) 18:27:53.44 ] > むしろ、同一メカニズムを使ってるのにあっちはダメでこっちはOKと考える > 根拠を聞きたいわ。 > svnがfileスキームで直接リポジトリにアクセスする場合も、svnserveがクライアン > トからの要求受けてリポジトリにアクセスする場合もlibsvn_reposが提供している、 > 同一のAPI使ってるんだよ。 馬鹿発見 178 名前：デフォルトの名無しさん mailto:sage [2012/02/27(月) 21:53:53.23 ] >>177 バカが現れた。どうする? 1) 戦う 2) 無視する 2 バカを無視した。 179 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 11:31:06.65 ] 致命的な馬鹿発言をさらしたのに、良くもそんな強気になれるな 180 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 11:42:13.91 ] どこが馬鹿なんだかわからない 181 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 13:35:52.55 ] >>180 クライアントの数が違うという差を無視したところがおかしいとおもうよ 182 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 13:37:47.25 ] クライアントの数なんて関係無いのに 183 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 13:46:32.97 ] >>181 君、上で議論してた人？ だったら聞きたいんだけど、「fileスキームはたとえ一人しかアクセスしなくても、ローカルリポジトリに限り 動作保証される」というのは正しい？ YesかNoかでお願い。 184 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 13:51:07.58 ] YesかNo 185 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 13:56:27.15 ] >>179 バカが現れた。バカは不思議な踊りを踊りだした。 どうする? 1) 戦う 2) 無視する 2 バカを無視した。 186 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 23:22:02.19 ] >>183 まぁちらちらと上でレスはしてたけど、白熱議論には参加してないよ。 今のところ得ている情報では、その質問の回答はYes 187 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 02:40:51.67 ] >>161 = >>181 = >>186 いちお。 188 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 08:29:35.79 ] debianとかの1.7がWANdisco版しかない理由をご存知の方 いらさいませんか？ 189 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 16:00:41.22 ] >>186 なら、俺と同じ意見だ。 上で「周回遅れがどうたら」の人は、Yesと思ってるのかNoと思ってるのか知りたい。 190 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 19:15:12.86 ] バカのむれが現れた。バカたちは何か相談している。どうする? 1)戦う 2)無視する 3)呪文 3 答えてやるから「動作保証」を定義しろ。 191 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 20:59:27.84 ] >>189 >>161で確認してるけど、どうやら「fileスキームは」ってところを除外してるみたいだよ。 192 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 01:32:53.81 ] なんでお前らはいまだにSubversion使ってるの？ 193 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 03:42:55.66 ] >>183 「fileスキームはたとえ一人しかアクセスしなくても、ローカルリポジトリに限り動作保証される」 日本語がなんかおかしくね あとFSFSの話に限定しないの？ 194 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 12:28:30.21 ] とりあえず、NASだとNTFSでもFATでもないものをFATとかに 見せかけてるだけだから、一人で使ってても、ロック関係の ファイルがおかしくなったりする。 195 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 12:58:54.19 ] >>190 「動作保証」は>>132と同じ意味で。 196 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 13:05:50.77 ] >>193 > >>183 > 「fileスキームはたとえ一人しかアクセスしなくても、ローカルリポジトリに限り動作保証される」 > 日本語がなんかおかしくね 「ローカルに無いリポジトリをfileスキームでアクセスする場合、たとえ一人しかアクセスしなくても動作保証されない」 と言い換えた方がいいかな。 > あとFSFSの話に限定しないの？ しない。 197 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 13:18:31.78 ] >>193 こう言った方がいいか。 開発チームは、 > file:// access is intended for local, single-user access only, particularly testing and debugging. と言ってる（>>150のリンク先の日本語訳はちょっとおかしい気がする）。 これ以外の使い方でも、何らかの動作保証がされてると主張してる人がいるのかどうか知りたい。 上の議論は話が錯綜していて、良くわからなかったので。 198 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:47:09.85 ] >>196 > file:// アクセスは、ローカルでの1ユーザーのみのアクセスを想定しており、そのようにテストとデバッグを行っています。 これだけで十分だろ。議論の余地なんてない 199 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:49:11.74 ] >>195 No 200 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 22:54:11.83 ] >>194 >とりあえず、NASだとNTFSでもFATでもないものをFATとかに見せかけてるだけ 意味わからん。 >> バカが現れた。 ってことなのか？ 201 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 00:26:32.22 ] 他の分散型(GitとかMercurialとか)のバージョン管理のファイルアクセスだとどうなの？ 202 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 11:03:17.82 ] >>198 その文章、>>197にも書いたとおり、訳がおかしいと思う。 >>199 「ローカルリポジトリに限り動作保証される」に対してNo？ もしそうだとしたら、何に対して動作保証してるの？ 203 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 11:34:27.78 ] >>176 SmartSVN（１万円近くする・・・）みたいに、 リビジョングラフでマージの導線が表示できるのが理想。 www.koreansoft.com/public/upload/SmartSVN/SmartSVN_09.png TortoiseSVNだとマージの導線までは引けないっぽいし、 Subclipseだとなぜか表示されないブランチがあったりなんかあやしい。 204 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 12:16:36.43 ] >>202 どこがおかしいかを書かないのは特別な理由でも？ その日本語のとおり理解をすれば動作保証の範囲も明確だろ。 205 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 12:17:06.03 ] >>203 TortoiseSVNのリビジョングラフってマージでないっけ 206 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 12:54:59.22 ] >>204 100%の自信があるわけじゃないから書いてないだけ。 > file:// access is intended for local, single-user access only, particularly testing and debugging. の訳が > file:// アクセスは、ローカルでの1ユーザーのみのアクセスを想定しており、そのようにテストとデバッグを行っています。 なんだが、最後のtestingとdebuggingは、for testing, for debuggingだと思う。 file:// アクセスは、テストやデバッグ目的でのローカルでの1ユーザーのみのアクセスを想定しています。 じゃないのかなぁと思う。 207 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 13:01:37.25 ] sambaやnfsを使えば、普通に使う範囲ではまぁ問題ないがな、位でしょ 208 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 14:12:16.39 ] >>206 その訳だと解釈した場合に、 テストやデバッグ目的でアクセスしていいけれど、リポジトリが壊れるかもしれない と思い至ったの？ 209 名前：208 mailto:sage [2012/03/02(金) 14:24:41.55 ] >>206 改めて必要なところを抜き出してみたよ。 > ネットワークフォルダー上のリポジトリにアクセスするには、ドライブ文字の割り当てと UNC パスの両方が使えます。 > Berkeley DB リポジトリは、ネットワークフォルダー上で作成したりアクセスしたりしないでください。 > FSFS リポジトリはネットワークフォルダー上に配置でき、 file:// プロトコルを用いて複数のユーザーからアクセスできますが、これは絶対にお勧め しません 。 > file:// アクセスは、ローカルでの1ユーザーのみのアクセスを想定しており、そのようにテストとデバッグを行っています。 > リポジトリを共有したい場合は、 まさに 適切なサーバーをセットアップする必要がある tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-repository.html#tsvn-repository-local-share 210 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 14:54:03.49 ] >>208 ん、誰かと勘違いしてない？ 俺自身は、リポジトリが壊れるかどうかという話はしてないよ。 （ちなみに排他がどうこうとも話してない） 開発側が > file:// access is intended for local, single-user access only, particularly testing and debugging. と書いてるが、開発者がこのようにintendした以外の使い方をしても、なんらかの 動作保証がなされているのか、なされているならどいう場合になされているのかを 知りたいってことなんだが。 211 名前：デフォルトの名無しさん mailto:sage [2012/03/02(金) 15:07:30.61 ] >>210 めんどくさい人だな。 テストやデバッグ目的で使用するにあたり、動作保証がされていない(リポジトリが壊れるかどうかに限定しない) と思ったってことならおｋ？ そんな状態でテストやデバッグする開発者がいると思えるのが不思議。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef