Subversion r11 - 暇つぶし2ch

Subversion r11 ..

396:デフォルトの名無しさん
09/04/20 11:45:15
>>393
svn:logではなく、svn:ignoreだけの話のように読めます。

397:デフォルトの名無しさん
09/04/20 13:21:19
>>396
いや、svn:logでも同じような問題が発生してる。

398:デフォルトの名無しさん
09/04/20 18:05:26
仕様もなにも↑で修正されてるじゃん

399:デフォルトの名無しさん
09/04/20 18:51:57
trunkにも取り込まれてないがな

400:351
09/04/20 21:32:02
亀レスですが、ご報告まで。

リポジトリサーバのpost-commit-hookで別サーバのワーキングコピーをsvn updateする件ですが、成功しました！
アドバイスを下さった皆様、ありがとうございました！

ポイントは2点ありました。
1. net useでネットワークドライブのマップを行う。
2. スクリプト（バッチファイル）内の実行ファイルはフルパスで指定。

出来なかったときは、net useコマンドにパスが通っていなかったのですね。
下のような記述で成功しました。

（\\server-b\svnwork\pub配下のワーキングコピーをupdateしたい場合。）
C:\WINDOWS\system32\net use X: \\server-b\svnwork
C:\Program Files\Subversion\bin\svn up X:\pub >> X:\pub\svnup.log 2>&1
C:\WINDOWS\system32\net use X: /delete

改めて感謝です！では！

401:デフォルトの名無しさん
09/04/22 20:39:28
non-LF の問題は行末に空白入れると回避できるな。

402:デフォルトの名無しさん
09/04/28 01:07:13
svnversion で末尾に P が付くのは何？

403:デフォルトの名無しさん
09/04/28 05:44:35
>>402 それ P やない、改行や。

とエスパーに挑戦してみる。 TortoiseMerge のアレのことなんだろうな、と。

404:デフォルトの名無しさん
09/04/28 12:33:20
C:>svnversion
128P

C:>svnversion --help
4123P まばらチェックアウト機能を用いて作られた部分的な作業コピー

google "まばらチェックアウト" で検索
|翻訳メモ:
| * sparse checkout は「まばらチェックアウト機能」としておいた。

・・・で、「まばらチェックアウト機能」て何？

405:デフォルトの名無しさん
09/04/28 13:10:29
>>403
ﾌﾟｷﾞｬｰ

>>404
URLﾘﾝｸ(tortoisesvn.net)
ここの「チェックアウトの深度」にある「再帰的」以外の指定のこと。

406:デフォルトの名無しさん
09/04/28 15:02:59
ﾌﾟｷﾞｬｰで台無し

407:デフォルトの名無しさん
09/04/28 15:04:04
>>406
必死だな

408:デフォルトの名無しさん
09/04/28 17:32:07
svn up --non-interactiveをsvn upのデフォルトにしたいんですが
configにそんな項目増えてたりしないんでしょうか。

まぁ、困るのはバッチ処理の時だけといえばそうなので
そこにいちいち書きくわえればいいといえばそうなんですが。。。

409:デフォルトの名無しさん
09/04/30 10:33:16
>>408
バッチファイル（シェルスクリプト）でラップすればいいのではないでしょうか。

410:デフォルトの名無しさん
09/04/30 16:01:59
svn diff
で、diffに渡されてるデフォルトのオプションって何？
-u -r -N
であってる？

411:410
09/04/30 16:28:10
自己解決しました

412:デフォルトの名無しさん
09/04/30 16:32:28
svn diff
で、diffに常に渡したいオプションがあるんだけどどうやって指定すればいい？

cvsのときなら.cvsrcに記述できたんだけど、.subversion/configには書くところがない

413:デフォルトの名無しさん
09/04/30 16:53:52
直上のレスぐらい見ろ

414:デフォルトの名無しさん
09/04/30 17:27:30
まぁ、シェルならふつーaliasだよね。

415:デフォルトの名無しさん
09/04/30 17:52:50
>>413
エイリアスやバッチで処理すれば出来ることはわかっています。
私は、オプションを常に指定する方法を調べています。

416:デフォルトの名無しさん
09/04/30 18:16:42
ソース弄るしかないんじゃない？

エイリアスのほうがインテリジェントだと思うけど。
そんな偉そうなら、用途をもっと明確にしてみそ？

417:デフォルトの名無しさん
09/04/30 18:19:32
そういや、svn diffって特定のもの以外のオプションをdiffコマンドに与えるのがクソ面倒だったような…

418:デフォルトの名無しさん
09/04/30 18:37:13
そう?
svn diff --diff-cmd=/usr/bin/diff -x -wu程度の話だと思うけど。

419:デフォルトの名無しさん
09/04/30 20:43:47
>>418
うん、そうなんだけど…なんでいちいち--diff-cmdがいるんだって話さね

420:デフォルトの名無しさん
09/04/30 21:33:15
あとあれ -L を勝手につけるのうざいよね。

421:デフォルトの名無しさん
09/04/30 23:14:27
そもそも1行に diff が3回も出てる時点でどうかしてる

422:デフォルトの名無しさん
09/05/01 00:27:55
>>418
これを「程度」とか言っちゃう神経がキモい

423:デフォルトの名無しさん
09/05/01 09:29:53
Tortoise使ってて文句つけるならわかるが、コマンドラインに文句つけるヒマあったら、
さっさとエイリアスかバッチ組むよ俺ならｗ

424:デフォルトの名無しさん
09/05/01 10:41:57
>>423
美しくないってことでしょ。
いきあたりばったりの実装で、設計思想に一貫性が無いという話。

425:デフォルトの名無しさん
09/05/01 11:08:37
所詮、ツールだし
そう言うもんだろうで終わらせるよ、俺なら

426:デフォルトの名無しさん
09/05/01 11:53:21
話が脱線するけど、あるソフト会社の作成したコンテンツにこんなのがあった。
仮に hoge 株式会社に納品したコンテンツだと仮定すると、
URLﾘﾝｸ(www.hoge.co.jp)
これがトップページのＵＲＬ。hoge が３回も出てくるんでみっともない。
ナントカっていうフレームワークを使用した結果、
ディレクトリ構成が決まってるためこうなってしまったらしい。
いったい何のために独自ドメイン取得したのか・・・
美しくない。

427:デフォルトの名無しさん
09/05/01 12:07:42
>>425
君の話はどうでもいい
そこらの電柱にでも話しかけていてくれたまえ

428:デフォルトの名無しさん
09/05/01 12:51:02
>>425さんマジパネェッス!!

429:デフォルトの名無しさん
09/05/01 12:53:19
>>426
うわあ…mod_rewriteぐらい使えよ

430:デフォルトの名無しさん
09/05/01 14:09:46
どうでもいいところをこだわっていて仕事になっているんなら、いいんじゃないか。
俺は利益に大きく結びつくところ以外は捨ててしまうが

431:デフォルトの名無しさん
09/05/01 14:30:06
こういう部分でエンジニアとしての程度が知れるな

432:デフォルトの名無しさん
09/05/01 14:32:07
切り捨てて良い部分に無駄にこだわって時間潰してるのを
有能と呼ぶなら俺は無能で良いわ

433:デフォルトの名無しさん
09/05/01 14:38:10
Subversion関係ねぇじゃん。

434:デフォルトの名無しさん
09/05/01 14:41:11
てゆか>>426はみっともない上にSEOにもかかわってくる可能性もあるしな
まあこの話題はそろそろ打ち止めってことで

435:デフォルトの名無しさん
09/05/01 18:26:24
無駄にこだわって時間潰す→無能
下手な設計で動くんだからいいじゃんと居直る→無能
最初から美しく設計する→有能

436:デフォルトの名無しさん
09/05/01 18:33:18
つまりSubversionを使うやつはみんな無能って事か

437:デフォルトの名無しさん
09/05/01 20:40:06
>>436
そりゃそうだ

438:デフォルトの名無しさん
09/05/01 22:17:42
実際さっさと git とかに移りたいんだけど
仕事で使ってるとなかなかそう簡単にはいかんのよねぇ・・・

439:デフォルトの名無しさん
09/05/02 11:24:12
git はオマンド体系とか違いすぎてなぁ
覚えるコストに見当った性能はあるのかしらん?

440:デフォルトの名無しさん
09/05/02 11:41:21
分散リポジトリ系のは今後どれが主流になるかもわからんし
ローカルでガリガリ書く時もコミットしたいってぐらいなら
svk でお茶を濁してていいんじゃね？

441:デフォルトの名無しさん
09/05/02 12:13:20
仕事で分散使う意味がわからん

442:デフォルトの名無しさん
09/05/02 12:17:09
>>440
svkはあるケースで遅くなるのがなぁ…

>>441
移動中にノートPCで開発してる奴なんて普通にいる
そういう場合に有利＞分散

443:デフォルトの名無しさん
09/05/02 12:17:56
>>439
URLﾘﾝｸ(www.tempus.org)
これ1ヶ月読んでわからなかったらあきらめた方がいい

444:デフォルトの名無しさん
09/05/02 14:12:55
>>443

多分そーゆー基本的なことを知りたいわけじゃないと思うよ

445:デフォルトの名無しさん
09/05/02 15:00:03
gitはUnix系では便利に使ってるけど、Windowsでは使えたもんじゃない。
svkはWindowsでもなんとかいける。

446:デフォルトの名無しさん
09/05/02 15:10:54
svkはGUIないから広めにくいんだよな。

最近は、Dropbox使う奴が周りでてきてる。
（もちろん、共有プロジェクトとか仕事では勧めてないが）
バージョン管理する必要がない、バージョン管理ソフトとして使えるのがいいらしい。

これくらいのシームレス差がほしいもんだけど

447:デフォルトの名無しさん
09/05/02 18:40:53
>442
＞移動中にノートPCで開発してる奴なんて普通にいる

そういうの、会社によるんじゃない？
うちの会社じゃ、そんなシチュエーション全く無い。

448:デフォルトの名無しさん
09/05/02 18:51:38
>>447
普通はそうだよな。
俺の会社でも10人程度の開発者がいるけど、全員が一つの机で顔をつきあわせながら開発するよ。
そういう状況で分散型VCSなど害悪でしかない。
当然ながらgitだのhgだのは一切使わないように支持が出されている。

449:デフォルトの名無しさん
09/05/02 20:25:23
>>448

速度面はどうよ。
ブランチとか使ってないの?

450:デフォルトの名無しさん
09/05/02 20:31:31
たしかに普通に社内で仕事する分には別に svn で困ることってそんなに無いんだよな。

履歴管理しなきゃいけない程の修正だったらブランチ切るし、
そもそも大きい修正なら一人で作業しない場合も多いし。

単に流行ってるからって理由で git 採用、とかは当然ながら止めといたほうがいいわな。
ただ OSS 関係は軒並分散リポジトリに移行しつつあるから追随しとかないと
参加出来なくなりつつあるけど。

451:デフォルトの名無しさん
09/05/02 21:11:47
> 単に流行ってるからって理由で git 採用、とか
いや全然流行ってねーしｗ

452:デフォルトの名無しさん
09/05/02 21:13:38
うちは、Linuxの設定ファイルの管理とか、ネットワーク的に断絶してる
外向きWebコンテンツの管理とかはMercurialで、プログラムのコードは
全部Subversionという使い分け。

自分の机以外で仕事のコードを書く事はほぼ皆無。
Mercurialは、難しくて使いにくいと他の社員から大不評をかっているので、
TortoiseHGの熟成をあと2年ぐらいは待ちたい感じ。

453:デフォルトの名無しさん
09/05/02 23:14:33
>>451
いや、流行ってるよ。
フリーでリポジトリ提供してるところで採用してるところ増えてるし
github とか使ってる人多いしな。

仕事で使ってるって話は 2ch の専用スレぐらいでしか聞かんけど。

454:デフォルトの名無しさん
09/05/03 06:36:28
gitｵﾜﾀ･･･
URLﾘﾝｸ(www.atmarkit.co.jp)

455:デフォルトの名無しさん
09/05/03 09:32:36
google code自体があんまり流行ってないってのもあるがな。

456:デフォルトの名無しさん
09/05/03 10:07:28
>>454-455
んー確かに。
ソースコードホスティングでいえば、githubばかりが目立つね
規模はgoogle code projectがでかいんだろうし、流行という感じでもないから、
sourceforgeみたいに、長く枯れるまで続けていくんだろうけどさ。

457:デフォルトの名無しさん
09/05/03 13:03:52
>>454
gitは使えねえので絶対に採用しませんとはどこにも書いてないわけだが

458:デフォルトの名無しさん
09/05/03 23:06:34
>>457
前向きだな。ｗ

459:デフォルトの名無しさん
09/05/03 23:13:17
何にしてもどこもかしこも分散型！って感じではあるな。
仕事関係は未だに CVS のところもあるというのに。

460:デフォルトの名無しさん
09/05/06 17:21:13
>>449
通常ブランチはよほどのことが無い限りすぐ本家に戻る

461:デフォルトの名無しさん
09/05/07 10:19:06
>>447
うちは持ち出し厳禁だし、ノートの持ち込みも入り口で名前書かされるし
出入りでカバンを簡単にチェックされるんで、svk使って持ち出しとかは出来ないんだよね

462:デフォルトの名無しさん
09/05/08 00:29:33
ネットワーク上に、新しいTortoiseSVNと古いTortoiseSVNを使うPCが
混在しても大丈夫でしょうか？リポジトリの作成を古いバージョンで
行えばよいように思いますがどうでしょうか？

463:デフォルトの名無しさん
09/05/08 00:34:17
>>462
メジャーバージョンが全部同じなら（全部 1.minor.patch なら）、効率は悪いけど
動作はすることになってる。
URLﾘﾝｸ(subversion.tigris.org)

464:デフォルトの名無しさん
09/05/08 02:26:17
２年ほど前に切ったブランチで開発し続けてたものをいきなりトランクにマージしろと言われました
そのブランチとトランクはもはや別のプログラムと言っていいほど違うものになってるんですが大丈夫なんですかね…
なんかコマンド打つのも怖いのですが

465:デフォルトの名無しさん
09/05/08 02:31:22
>>464
↓こっちのがいいんじゃね？
svn mv trunk branches/dead-trunk
svn mv branches/active trunk

466:デフォルトの名無しさん
09/05/08 02:42:54
>>465
その方が良いですね
交渉してみます
ありがとうございました

467:デフォルトの名無しさん
09/05/08 07:09:44
おまいら全部コマンドうちなの？
亀使わないの？

468:デフォルトの名無しさん
09/05/08 08:10:46
亀以外にもフロントエンドは色々あるわけだし、
ここで話するときは共通言語のコマンドで書くってだけの話じゃね？

469:デフォルトの名無しさん
09/05/08 16:49:02
特定のファイルをリポジトリから完全に削除ってdumpを使って出来るじゃないですか？

で、ある特定の日付以前に削除されたファイルを完全削除して掃除ってできますか？

cronとかで毎日掃除して、無駄な容量の増加を防止するとか

470:デフォルトの名無しさん
09/05/08 21:44:34
>>469
削除したブランチを消去するフィルターが欲しいなあ

471:デフォルトの名無しさん
09/05/10 13:45:06
TortoiseSVN 1.6.2 age
URLﾘﾝｸ(sourceforge.net)

472:デフォルトの名無しさん
09/05/10 14:19:20
>>471
- BUG: Error message about non-LF commit messages when using messages with
non-ASCII text. (Stefan)

わーい、直った。

473:デフォルトの名無しさん
09/05/10 15:09:03
結局TortoiseSVN側での対応か。
本家のtrunk(r37666)では未だエラーになる。

474:デフォルトの名無しさん
09/05/10 16:01:36
>>473
ＴｏｒｔｏｉｓｅＳＶＮの開発者に感謝するよ。

でもこの問題ってdump/loadは影響しないのかな？

475:デフォルトの名無しさん
09/05/11 13:54:56
1.6.2って何かおかしくねえ・・・・？
同僚含めてちゃんとインストール出来ないんだけど・・・
修復セットアップしたら何とか入ったけど言語パックはどうやっても入らない

476:デフォルトの名無しさん
09/05/11 13:55:56
何の問題もなく入ったけど、、、ってx64版だし参考にはならんか

477:デフォルトの名無しさん
09/05/11 14:06:46
うちでは、1.6.1をアンインストールして1.5.9を入れたところ、
言語パックを入れてもLanguageのリストにEnglishしか存在しない。
これも >>475 と関係あるのかな？

478:デフォルトの名無しさん
09/05/11 14:13:16
うちは1.6.2にしたらエクスプローラが死ぬようになったから
NightlyBuild版に戻したよ。

479:デフォルトの名無しさん
09/05/11 14:20:33
こっちも何かインストールが上手く行かなかったけど、
アンインストールして綺麗にしてからやったら上手く行った。

480:デフォルトの名無しさん
09/05/11 16:38:20
>>477
Languageフォルダーを削除してから、もう一度インストールしてみて。

481:21
09/05/11 17:36:09
本家の 1.6.2 はリリースされないの？

482:デフォルトの名無しさん
09/05/11 21:35:09
リリースされました。

　User-visible changes:
　　* vastly improve memory usage with 'svn merge' (issue #3393)
　　* make default depth for merge 'infinity' (r37156)
　　* make 'status --quiet' show tree conflicts (issue #3396)
　　* allow '--set-depth infinity' to expand shallow subtrees (r37169)
　　* return an error if attempting to reintegrate from/to the repo root (r37385)
　　* don't store bogus mergeinfo for '--ignore-ancestry', foreign merges (r37333)
　　* don't allow merge of difference between two repos (r37519)
　　* avoid potential segfault with subtree mergeinfo (r36613, -15, -31, -41)
　　* recommend sqlite 3.6.13 (r37245)
　　* avoid unnecessary server query for implicit mergeinfo (r36509)
　　* avoid unnecessary server query during reverse merges (r36527)
　　* set depth=infinity on 'svn add' items with restricted depth (r37607)
　　* fixed: commit log message template missing paths (issue #3399)
　　* fixed: segfault on merge with servers < 1.6 (r37363, -67, -68, -79)
　　* fixed: repeat merge failures with non-inheritable mergeinfo (issue #3392)
　　* fixed: another memory leak when performing mergeinfo-aware merges (r37398)
　　* fixed: incorrect mergeinfo on children of shallow merges (issue #3407)
　　* fixed: pool lifetime issues in the BDB backend (r37137)

　Developer-visible changes:
　　* don't fail if an embedding app has already initialized SQLite (issue #3387)
　　* resolve naming collisions with static stat() function in svnserve (r37527)
　　* fix an expectation for a failing dirent windows test (r37121)

483:477
09/05/12 10:12:35
>>480
いちどLanguageフォルダーを削除してから言語パックを入れたところ
English以外もリストに表示され、選択することができました！
ありがとうございました。

484:デフォルトの名無しさん
09/05/16 13:11:05
ドライブの中にいろんなところからチェックアウトしたワーキングコピーが
ちらばっているのだけど，どこから何をチェックアウトしたのか
ドライブ全体をくまなく探索して列挙してくれるようなツールってない？

「お前，随分前にチェックアウトして変更点あるのにコミットしてない
　ワーキングコピーがあるよ？」とか警告してほしい．

WindowsでTortoiseSVNを動かしていればそのキャッシュには
すべてのワーキングコピーの所在に関する情報が含まれて
いるんだろうけど，そこにアクセスする手段がない．
TortoiseCacheにAPIが実装されていればなぁ・・・

485:デフォルトの名無しさん
09/05/16 13:42:01
TortoiseSVN でローカルのファイルシステムにリポジトリを作るとき
作成するリポジトリのフォーマットのバージョンを指定することって
できないでしょうか．

互換性のためひとつ前のバージョンのフォーマットで
リポジトリを作りたいのですが，昔のTortoiseSVNを
インストールするしかないでしょうか．

486:デフォルトの名無しさん
09/05/16 17:03:14
>>484
.svnで検索

アイコンオーバーレイの範囲も狭められるからチェックアウトするフォルダぐらい決めておけよ。

487:デフォルトの名無しさん
09/05/16 19:46:46
>>486
まぁ基本的にはチェックアウトするフォルダは限定するよな．

それはそうなんだけど，
svn:externals でチェックアウトしたワーキングコピーに
修正をかけても，その上位のワーキングコピーの
オーバーレイアイコンには反映されないので，忘れてしまう．

488:デフォルトの名無しさん
09/05/16 20:37:47
>>487
externalsのフォルダーもオーバーレイアイコンは反映されるけど？
コミット時もグレイ化された状態で一覧にも出るけど。
1.6.2です。

489:デフォルトの名無しさん
09/05/16 20:43:32
>>488
上の階層にまではそれが伝播しないんじゃない？
とりあえず最新のTortoiseSVNにしてみるか．

490:デフォルトの名無しさん
09/05/16 21:03:12
>>489
ルートの方へのexternalsはコミット時に出るかはやったこと無いけど、サブディリクトリ方向には伝播して表示する。
オーバーレイするディリクトリのマスクから外れたワーキングコピーは伝播しなかったと思う。
c:\working* のように*は入ってる？

491:デフォルトの名無しさん
09/05/26 04:32:34
TortoiseSVN 1.6.2
sambaの共有フォルダ上で使用しています。
変更ファイルに対して"元に戻す"を実行しても「ファイルリストは空です」になってしまい元に戻せません。
ググって URLﾘﾝｸ(blog.longkey1.net) 等も試したのですがダメです。
ローカルドライブであれば問題ありませんので原因はsambaでの設定かなと考えています。
("SVN更新"、"SVNコミット"は問題なく利用できています。)
何か情報をお持ちの方ヒントを下さい。
よろしくお願いします。

492:491
09/05/26 04:46:40
あ、あああ・・
「変更ファイルに対して」ではなくて「変更ファイルのフォルダに対して」、"元に戻す"で対象ファイルが
表示され無事元に戻すことができました。
お騒がせしてすいませんでしたm(_ _)m

#1.6.2で仕様変更されたんですかね・・・Orz

493:デフォルトの名無しさん
09/05/26 05:50:47
svn moveのオプションなんですが、hgやらbzrにある
--afterみたいなオプションは無いですか？

WC内でmvコマンドを使って実際に移動させてから
svn moveする、という使い方がしたいわけです。

というのも、svn moveはcopy+deleteなので、
WC内ファイルのハードリンク情報が消えてしまうからなんです。

なんかいい方法ないでしょうか？

494:デフォルトの名無しさん
09/05/26 11:55:29
cp
svn mv
cp

495:デフォルトの名無しさん
09/05/26 13:31:04
Subversionのマルチユーザー(というか複数人で使う)運用についてお聞きします。

ssh+svnで運用したいのですが、リポジトリにコミットするときのユーザーが問題です。
ユーザーsvn_userさんを作って svn+ssh://example/test-repo/trunk などでアクセスすると思うのですが、
svn_userさんに.ssh/authorized_keys などを適切に設定し、他の人もsshでログインできるようにした状態で、
svn_userさんでアクセスすると、他の人がコミットしたユーザーも全てsvn_userさんだけになってしまいます。

複数人で使う場合に、コミットするユーザーを分けようとすると、
これはコミットする人ごとにユーザーを作ってsshでログインできるようにして(.ssh/authorized_keysなどを適切に設定)、
コミットしなければならないということでしょうか？

Mercurialなどではローカルでユーザー名を設定して、
ユーザーhgを作って、
ssh://hg@example.com/hg-test-repo
などのようにアクセスしてコミットとpushするだけで、マルチユーザーで使えるのですが…。

どのようにしたものなのでしょうか？

496:デフォルトの名無しさん
09/05/26 13:48:26
>>495
svn_userのauthorized_keysで
command="/usr/bin/svnserve -t -r /repository/dir" --tunnel-user userA ......公開鍵A
command="/usr/bin/svnserve -t -r /repository/dir" --tunnel-user userB ......公開鍵B
って感じで認証鍵で振り分けるのはどうよ。これなら一つのユーザで済むと思う。

497:デフォルトの名無しさん
09/05/26 13:49:53
>>496でダブルクォーテーションの括り方がおかしかった、ｽﾏｿ。

498:デフォルトの名無しさん
09/05/26 15:19:53
>>496
ありがとう！

それらのキーワードでぐぐったら、けっこうドキュメントがでてきました。
svnserve, 専用サーバ
URLﾘﾝｸ(subversion.bluegate.org)

やりたかったことができそうです。試してみたいと思います。

499:493
09/05/26 16:10:26
>>494
すいません。ちょっと意味が分からないので詳細教えてください。
最初にコピーするというのは、mvする前にどっかに避難させるということでしょうか？
cpしたらリンクが消えてしまうので一緒の気がするのですが、違いますでしょうか？

500:495
09/05/26 16:49:59
authorized_keys で以下のように書くことで、svn_userのみで鍵に応じてfoobarさんで
無事にコミットできるようになりました。

　command="svnserve -t --tunnel-user=foobar" (以降公開鍵)

そこで、つまづいてしまったのですが、
上記方法だと、svn_userでsshでシェルログインして svnadmin create などもできなくなってしまいます。
もし、sshシェルアクセスもさせたい場合は別の鍵を追加するしかないのでしょうか？

501:デフォルトの名無しさん
09/05/26 19:32:52
>>500
そう、別鍵を用意する。

502:デフォルトの名無しさん
09/06/01 10:18:20
TortoiseSVNとEclipseのsubversiveを併用してるんだけど、
subversiveでチェックアウトしてる作業コピーをTortoiseSVNでいじった後に、subversiveでコミットしようとしたらバージョン違いがどうたらってエラーが出た。
今までバージョンがあるのはリポジトリだけだと思ってたんだが、作業コピーにもバージョンってあるのな。
でもsubversiveのためにTortoiseSVNのバージョン下げるとかめんどい・・・。

503:デフォルトの名無しさん
09/06/01 12:27:14
>>502
Subversiveは捨てて、Subclipseに移ればいいよ。
SubclipseはSubversion1.6に対応している。
URLﾘﾝｸ(subclipse.tigris.org)

504:デフォルトの名無しさん
09/06/01 13:13:17
Subversiveはまだ開発途上です。
いずれSubclipseが主流になる日が来るかもしれません。
でも今は未だそのときではありません。
Subversiveが成長するまで温かく見守ってあげましょう。

505:デフォルトの名無しさん
09/06/01 13:14:07
Subversiveはまだ開発途上です。
いずれSubclipseの座を奪って主流になる日が来るかもしれません。
でも今は未だそのときではありません。
Subversiveが成長するまで温かく見守ってあげましょう。

506:デフォルトの名無しさん
09/06/03 03:03:32
最近 subversive は標準になるなる詐欺なんじゃないかと思うときがあるよw

507:デフォルトの名無しさん
09/06/03 11:04:16
SVK の代わりに何を使えばいいの？
URLﾘﾝｸ(lists.bestpractical.com)

508:デフォルトの名無しさん
09/06/05 03:12:57
>>507
今年中にはbzr-svnが実用レベルになる。

509:デフォルトの名無しさん
09/06/05 06:04:56
bzrはやるやる詐欺

510:デフォルトの名無しさん
09/06/05 10:05:05
>>509
色々手を出しすぎて完成度が低かったけど、bzr2.0に向けて着々と
完成度上がってきてるよ。
本当にbzr-svnがsvk以上になるかどうかはさておき。

511:デフォルトの名無しさん
09/06/05 10:13:18
1.1の頃に作ったリポジトリ(途中で一回bdb->fsfsに移行した)をダンプして
1.5で作り直したら800MB->500MBになったのだが、ここまでになるとは
思っていなかったので驚いた。

おまいらはメジャーバージョンが上がったらdump/create/loadしてる？
それともsvnadmin upgradeで誤魔化してる？

512:デフォルトの名無しさん
09/06/05 23:56:47
ひとつのリポジトリでリビジョン番号が約 25000、
総容量(fsfs)が 60GB くらいあるので、
dump/load なんてやる根性ないっス。

513:デフォルトの名無しさん
09/06/06 00:19:06
>>512
何のリポジトリっすかｗｗ

514:デフォルトの名無しさん
09/06/06 00:28:57
>>512
画像や音声データが入ってるな。ゲームの開発か？

515:デフォルトの名無しさん
09/06/06 02:23:06
ドキュメントの版管理やったらギガは結構すぐ行くな
ExcelとかPowerPointで10Mくらいあるのガンガン更新したりするし

516:デフォルトの名無しさん
09/06/06 16:14:58
512でつ。
商用ソフトの開発でつ。
画像なんかは入っていません。
純粋にVC++のソースと、そのときのコンパイル済みバイナリ(*.exe/*.dll)、
それからインポートライブラリです。

インポートライブラリが大きいといえば確かに大きいですが、
これをコミットするのはモジュールI/Fが変わったときだけなので、
総コミット数からみると何十回かに一回くらいじゃないかと思います。

6年前にCVSでSCM化したときから始まっています。
ちなみにリビジョン1のコミット日時は 2003-03-31 10:55:20 +0900 とあります。
最も古いソースは10年ほどになりますか。
商品自体はもっと前からありますが、これ以前は私は他の事業部にいたので、
「このソースは私のローカルが最新」なんて世界だったそうです。

517:デフォルトの名無しさん
09/06/06 16:21:21
>「このソースは私のローカルが最新」なんて世界だったそうです。
SCM化してるにもかかわらずこんなことのたまう人がたまに居たりして
頭痛くなるんだよねw

518:デフォルトの名無しさん
09/06/06 16:46:58
>>516
金曜日に帰宅する前にdump/loadを自動で仕掛けておけば、翌週には
リポジトリがスリムになっているだろうな。是非やってみてくれ。

519:デフォルトの名無しさん
09/06/06 19:21:22
6年分とか怖くて出来ないな…。

520:デフォルトの名無しさん
09/06/06 19:30:14
> はてながgitに移行できた、たった1つの方法。
> 2008/04にSVNリポジトリが壊れた！
> リビジョン35000くらいのリポジトリ破壊！
> おわたおわたー！

デブサミ2009「株式会社はてなの開発戦略」講演メモ - RX-7乗りの適当な日々
URLﾘﾝｸ(d.hatena.ne.jp)

はてなみたく次に乗り換えるのはぶっこわれた時、なんてならんようにな…

521:デフォルトの名無しさん
09/06/06 20:50:56
うちもリビジョン3000くらいのリポジトリが先月破損したけど
水銀と天秤に掛けた上で結局svnで再構築した

522:デフォルトの名無しさん
09/06/06 20:56:51
使い始めてまもないんだけど
時々壊れるものなん？

523:デフォルトの名無しさん
09/06/06 21:30:45
どんなツールでも壊れることはあるよ
俺はCVSとVSSでも壊れたの見たことある

524:デフォルトの名無しさん
09/06/06 21:35:39
>>520みたいにHDDが壊れたとかはsvnのせいじゃないしなあ。

ところでこの記事に、「gitはブランチの作成が一瞬」ってあるけど、svnもそうだよな。
作業コピーの切り替えのことかな？

525:デフォルトの名無しさん
09/06/07 02:11:53
おまいらdumpもろくにしないのか？一度フルで取っておけば、
後はそのリビジョンから部分的にdumpするだけでいいのに。

そして怖いっていうのが良く分からん。
既存のリポジトリはそのまま温存しておいて、新規にリポジトリを作成して
そこにloadすれば良いんだぞ。

526:デフォルトの名無しさん
09/06/07 02:42:48
壊れるのが怖いならディスクにデータ書き込めない罠
何年も付けっぱなしのサーバでファイルが破損ってのはリポジトリに限らずあり得る話だし
特にバイナリファイルは

527:デフォルトの名無しさん
09/06/07 05:57:17
>>525-526
リポジトリが壊れるのが怖くてリポジトリのダンプを今度はバージョン管理下におくわけですね。わかります。

528:デフォルトの名無しさん
09/06/07 06:23:41
わかってねぇな

529:デフォルトの名無しさん
09/06/07 11:49:39
>>518
512でつ。
thx.
土日も害中三がコミットしてくるので、あらかじめアナウンスしとく必要があります。
来月には新しいバージョンをリリースするので、そのときにスケジュールとってやってみます。

530:デフォルトの名無しさん
09/06/07 12:08:34
dump/loadは使っていませんが、リポジトリのバックアップ自体はとっています。
fsfsなのをいいことに、毎晩、地理的に離れた場所にあるサーバにssh+rsyncしています。

まぁこれも、dumpで差分だけコピるようにすればはるかに効率的なんですが、
スクリプト書く手間が面倒だからズボラしているというのが正直なところです。

でも、その言い訳をするわけではありませんが、
dump/loadだとリビジョンが2万も3万もあるリポジトリを復旧するまで業務が止まってしまうので、
毎晩のrsyncに多少時間がかかっても、会社組織での運用という面ではこれもアリなのかなぁ...と。
rsync自体も今のところ1～2時間で終わっているので、当分の間は十分に許容範囲です。

531:デフォルトの名無しさん
09/06/07 12:30:36
>>529
>>518だが、やったら是非結果をレポートしてくれ。
一つ言っておくと、リポジトリを置いてあるマシン周辺のディスク容量に問題が
無ければ、毎晩リビジョンを2000ずつとか、一晩で終わりそうな分だけdump/load
するというのもあり。これだとダウンタイムほぼ無しで行ける。

>>530
それでも良いかもね。ただし、特定のリビジョンが壊れているといけないので、
バックアップを取った後にsvnadmin verifyはかけておいた方がいいな。

532:デフォルトの名無しさん
09/06/07 13:07:11
>>531
色々thx.
来月、スケジュールを立ててやってみて、結果をご報告します。
その前にディスク容量を空けとかないと。(藁

svnadmin verifyまでは考えが及びませんでした。
リモートのサバ缶(うちの害中三)に伝えておきます。

533:デフォルトの名無しさん
09/06/07 16:33:00
>>527
ネタにもなってないし、言い回しは腐ってるしｗ

534:デフォルトの名無しさん
09/06/07 17:40:10
>>530
rsync使う場合、マスタのfsが壊れてそれに気づかずにバックアップ側にrsyncかけて
バックアップまでこわしちゃう可能性があるから、やっぱり万が一に備えて時々
差分dumpを取って物理的に離れたストレージに保存する方がいいよ。

535:デフォルトの名無しさん
09/06/07 17:50:49
たまにLinuxのディス鶏なんか
ぶっ壊れたisoがミラーにばらまかれて全米が泣いたりすることあるしな

536:デフォルトの名無しさん
09/06/07 17:53:44
でもはてながリポジトリのバックアップ取ってなかったってお笑いだよな。

537:デフォルトの名無しさん
09/06/07 18:07:23
取ってないってか取れないだろうなリビ3万越えとか
バージョン管理が目的じゃなくてバックアップすることが目的くらいの勢いになっちゃうわ

538:デフォルトの名無しさん
09/06/07 18:10:33
>>537
お前は今までのスレの流れを読んだ上でそんなことを言ってるのか？
インクリメンタルバックアップを取れば良いだけの話だ。

539:デフォルトの名無しさん
09/06/07 18:13:31
実際バックアップ取ったことないだろ。
そんな簡単な話じゃないぞ。

540:デフォルトの名無しさん
09/06/07 18:14:31
実際にやっているから言っているんだが。何がどう難しいか言ってみろ。

541:デフォルトの名無しさん
09/06/07 18:28:45
インクリメントする元の過去の部分が壊れててもだれも気がつかない

542:デフォルトの名無しさん
09/06/07 18:31:36
>>541
？？？
リポジトリの特定リビジョンが壊れていたらそもそもdumpに失敗するわけだが。

543:デフォルトの名無しさん
09/06/07 18:32:35
やったことない奴が会話に紛れこんでるってことか
どっちかしらんが

544:デフォルトの名無しさん
09/06/07 18:35:29
流れからしてsageてないやつが犯人

545:デフォルトの名無しさん
09/06/07 18:39:22
dumpする側じゃなくてマージする側だろ
最新版は取り出せても過去のものは取り出せなくなる

546:デフォルトの名無しさん
09/06/07 18:41:34
>>545
そんなものは運用の問題だろうが。
dumpしたファイルのmd5sumでも取っておけば済む話。

547:デフォルトの名無しさん
09/06/07 18:44:52
ダンプする側じゃないと何度言えば
ダンプしたときは壊れて無くても
ファイルを置いておけば壊れる可能性がある
その壊れたものにマージしていったら過去の部分は壊れたまま
そこが必要になって取り出してみるまで気がつかない

548:デフォルトの名無しさん
09/06/07 18:45:44
そして本体が破損してバックアップから戻そうとすると
そっちも壊れていることが発覚して全米が泣くと

549:デフォルトの名無しさん
09/06/07 18:46:55
ぶっちゃけ実務で必要なのって近1週間分くらいだからバックアップ取らないんだろはてなも
ソースコード保存マニアなら、最古のコードまで保存したいんだろうけど

550:デフォルトの名無しさん
09/06/07 18:48:06
リポジトリじゃないけど、DBの差分バックアップで泣いたことは確かにあるわ。
バックアップの度にベリファイしてたらきりないし、結局トレードオフだよね。

551:デフォルトの名無しさん
09/06/07 18:48:54
>>547
だからdumpファイルのmd5sumを取ればいいと言ってるだろうが。
こんな簡単なことも考えつかないのか？

552:デフォルトの名無しさん
09/06/07 18:49:50
まぁだからOracleもわざわざコールドバックアップなんてものをやるわけだから
結局フルバックアップしない限り、バックアップが完璧になることはないよ

553:デフォルトの名無しさん
09/06/07 18:51:18
>>551
意味ないでしょそれ比較しても
本当にdumpしてる？

554:デフォルトの名無しさん
09/06/07 18:53:59
壊れたファイルのmd5sum取っておいて
あとで比較して一致したのでめでたしめでたしと壊れたファイルを保存するオチだな
バックアップ後に試しにリストアしてみて本当に正しいかどうかチェックしてsum取らないと

555:デフォルトの名無しさん
09/06/07 18:54:00
>>553
だからどう意味が無いんだ？

定期的にmd5sumをチェックすれば
> ダンプしたときは壊れて無くても
> ファイルを置いておけば壊れる可能性がある
という問題は完全に防げるだろうが。

556:デフォルトの名無しさん
09/06/07 19:02:39
>>554
dumpした直後にファイルが壊れるような信頼性の低いシステムを使うことが間違い。

> バックアップ後に試しにリストアしてみて本当に正しいかどうかチェックしてsum取らないと
お前の言うような信頼性の低いシステムでは、そんなことをしても正当性を
チェック出来ないぞ。

557:デフォルトの名無しさん
09/06/07 19:05:30
>>553
お前の使うシステムではdump直後にファイルが壊れてる確率がそんなに高いのか？

558:名無し募集中。。。
09/06/07 19:12:03
なんかもう人格否定じゃん

559:デフォルトの名無しさん
09/06/07 19:16:39
どこが人格否定なんだよ

560:デフォルトの名無しさん
09/06/07 19:20:00
システムの信頼性に疑問がないならそもそもバックアップいらないんじゃねみたいな

561:デフォルトの名無しさん
09/06/07 19:25:54
おまいら、頭を冷やせ
非現実的な極論ばかり言っても仕方ないだろ

562:デフォルトの名無しさん
09/06/07 19:37:41
人のやり方を否定するより、

私はこうやってますよ。あなたの方法よりこんな点が優れてますよ。

って書いて欲しい

563:デフォルトの名無しさん
09/06/07 20:14:18
うちは hotcopy で毎日バックアップ取ってる（前７日分まで保持）。
dump/load は、Subversion のバージョンアップの際、
リポジトリフォーマットの互換がない場合にしか使わないなー。

564:デフォルトの名無しさん
09/06/07 20:17:34
>>563
リポジトリが大きすぎなければ、hotcopyが一番楽だよな。

565:デフォルトの名無しさん
09/06/07 20:22:39
dumpは運用としては現実的じゃないよね

566:デフォルトの名無しさん
09/06/07 20:25:32
うちはリポジトリ(9個ある)ごとに、svnadmin hotcopyして、svnadmin verifyして、tar.gz で圧縮して別ディスクに格納。これを最新10日分保存。

以上の作業を行うシェルスクリプトを、Hudsonで1日1回, 5:45から実行している。
スクリプトの実行時にエラーが発生したらメールで通知されるし、スクリプトが標準出力・標準エラー出力に表示した文字はすべてHudsonがログを保存してくれるので便利だ。

567:デフォルトの名無しさん
09/06/07 20:26:46
>>565
それはケースによるね。上で議論になっていた60GBもあるような
巨大なリポジトリだとhotcopyが非現実的になり得るわけだから。

568:デフォルトの名無しさん
09/06/07 20:44:01
巨大リポジトリだとそれこそ過去の分は不必要だろうから
はてなみたいに捨ててしまえばいいのさ

569:デフォルトの名無しさん
09/06/07 20:55:38
論理が飛躍しすぎていて何を言っているのか分からん
>>512が関わっているようなリポジトリで過去の分が不必要だなんてことは無いだろ

570:デフォルトの名無しさん
09/06/07 21:56:51
dump は、 rev0-rev1000 みたいに部分的に取ることもできるし、
--increment を使わないで古いリビジョンを捨てたdumpを取る
事もできる。
マスタが壊れたときには、 --increment を使わない「浅い」dumpを
復元して一時的に運用を続け、深いdumpを時間を掛けて復元すれば良い。

・・・で、合ってる?

571:デフォルトの名無しさん
09/06/08 05:26:56
subversionを捨てればいいんじゃないか、

572:デフォルトの名無しさん
09/06/09 09:56:48
必要な時だけ読めれば良いとか、そんな程度でしかないと思うけど

573:デフォルトの名無しさん
09/06/14 17:12:33
SVNのリポジトリは過去リビジョンのファイルは変化しないので、HOTCOPYを差分バックアップすれば済むと思うんだけど、どうかな

574:デフォルトの名無しさん
09/06/14 19:29:40
>>573
昔の部分が壊れた場合、差分バックアップのときに壊れた部分も差分として
バックアップされない?
その後、差分の中から壊れてない部分を抽出するのが面倒。

逆に、 dump と dump --incremental でまずいのは何?

575:デフォルトの名無しさん
09/06/14 19:37:23
>>573
運用で避けられるし使わないことが多いと思うが、過去のリビジョンの
プロパティを変更出来るので結局差分バックアップは完全ではないんだよな。
やっぱりhotcopyが一番楽かつ安全性が高いということになる。

576:デフォルトの名無しさん
09/06/15 11:34:08
結局、「大容量のファイルをいかにバックアップするか」という普通のバックアップの話になると思う。
毎月フル、毎週差分、毎日修正ファイルのみ、みたいな。

577:デフォルトの名無しさん
09/06/15 17:55:53
svn のバージョンアップに強いのは dump? or hotcopy?

578:デフォルトの名無しさん
09/06/15 18:05:02
>>577
当然dump。dump/loadは基本的にコミットログのリプレイだから。
リポジトリを完全にアップグレードするにはdumpするしかない。

579:デフォルトの名無しさん
09/06/16 21:04:02
svn commit のときに changelist に含まれないものだけコミットする方法はありますか?

580:デフォルトの名無しさん
09/06/17 17:11:30
subversionの運用について教えてください。

svn + apacheでmod_svnを使った運用を考えています。
リポジトリとプロジェクトの関係で2つの方法があると聞きました。

１．1リポジトリに対して複数のプロジェクトを管理
/home/svnにsvnadmin createして、配下にsvn importしていく。
りビジョンが通しで付くので1プロジェクトに対し一貫性がない。
svnadmin createが1回だけですむ。hookscriptを一度定義すればよい。

２．1リポジトリに1プロジェクト
/home/svnの下にプロジェクトごとにsvnadmin create する。
リビジョンはプロジェクト単位で一貫性がある
ただしプロジェクトが発生するたびにsvnadmin　createする必要がある。
hookscriptなどをその都度用意する必要がある。

皆さんはどんな風に運用していますか？
設定は２で、１のように1リポジトリに複数という形式もありかなあと思っていますが、
実運用っぷりをきいてみたいです。

581:デフォルトの名無しさん
09/06/17 17:26:00
運用、運用って言うけど、
結局、どのくらいの頻度で新しいプロジェクトが立つかだけじゃないの？

リビジョン番号の一貫性云々言うけど、
どうせ branch + trunk でごちゃごちゃになるし、
別にたいした問題だとは思わないけどね。

582:デフォルトの名無しさん
09/06/17 18:15:17
>>580
1リポジトリで複数プロジェクトにしておけば、
あとは特定のディレクトリ以下を別リポジトリに独立させることができるよ。
ただし、ディレクトリ作成を独立したコミットにしておく必要がある。

583:デフォルトの名無しさん
09/06/17 18:37:18
レポジトリのログを一覧して見たときに、
自然なまとまりになるであろうようにする。

それが俺ルール。

584:デフォルトの名無しさん
09/06/18 11:16:40
リポジトリ vs レポジトリ論争がまた始まりそうな予感

585:デフォルトの名無しさん
09/06/18 11:26:13
あろうようにする

586:デフォルトの名無しさん
09/06/21 23:50:40
TortoiseSVN 1.6.3 age
URLﾘﾝｸ(sourceforge.net)

587:デフォルトの名無しさん
09/06/22 10:19:04
前回も確かそうだったが、最近Subversion本体よりTSVNの方が
（少なくともWebでは）先にリリースされとるな。
チーム内で何か確執でもあるのだろうかｗ

588:デフォルトの名無しさん
09/06/22 10:22:58
サーバーを1.5.4で運用しているのだが、クライアントを1.6.xにすると
どの程度遅くなる？無視できる程度？
ちなみに使っているプロトコルはsvn+sshです

589:デフォルトの名無しさん
09/06/23 03:59:50
ちと質問。

勉強でTortoiseSVN1.5.6を使用し始めて、その後コマンドライン版svn1.5.6を使用中。
リポジトリはTortoiseSVNでローカルに作成したものを使ってます。
OSはWindowsXP。

1.6.3が出るようなのでサービスを稼働させる前にバージョンアップしようかと思ってますが、
どの程度互換性があるのか今一つわかってません。

・ワーキングコピーは非互換部分あり、バージョンアップ後に再度チェックアウトし直しがベスト
・リポジトリは互換性あり、気になるならバックアップしておく程度でよし

というのがこのスレ読んで考えた対処法ですが、合ってますでしょうか。

590:デフォルトの名無しさん
09/06/23 04:42:10
>>587
TortoiseSVN の開発チームは Subversion 開発チームとはまったく別。

TortoiseSVN のビルド～リリース手順は Subversion 側のタグ作成が済んだら始まる。
その手順が Subversion 側のタグ作成～リリースの手順よりも速いってだけ。

591:デフォルトの名無しさん
09/06/23 04:44:06
>>588
実測しないとなんとも。

592:デフォルトの名無しさん
09/06/23 04:50:16
>>589
> ・ワーキングコピーは非互換部分あり、バージョンアップ後に再度チェックアウトし直しがベスト

非互換部分があるのは合ってるけど、チェックアウトしなおす必要は無い。
1.6 のクライアントでアクセスすれば勝手にバージョンアップされる。

> ・リポジトリは互換性あり、気になるならバックアップしておく程度でよし

互換性があるんでそれでもいいけど、 1.6 でしかアクセスしないなら 1.6 で
作り直したほうが１～２割ほど容量が抑えられてうれしいかもしれない。

詳しくはこちら。っていうかこっち先に読めよ。
URLﾘﾝｸ(subversion.tigris.org)

593:デフォルトの名無しさん
09/06/23 21:58:17
>>338 >>472の件、ようやく本家で対応されますた

Version 1.6.3
(19 Jun 2009, from /branches/1.6.x)
URLﾘﾝｸ(svn.collab.net)

User-visible changes:
* fix segfault in WC->URL copy (r37646, -56)
* let 'svnadmin load' tolerate mergeinfo with "\r\n" (r37768)
* make svnsync normalize svn:* props to LF line endings (issue #3404)
(略)

594:デフォルトの名無しさん
09/06/25 10:57:48
Version 1.6.3
URLﾘﾝｸ(sourceforge.net)

大量にバグが修正されてますな

595:デフォルトの名無しさん
09/06/25 19:47:35
TortoiseSVN1.6..3にバージョン上げたんだけど
コミットする時の対象一覧が常に空と表示されるようになって
選択されてない状態になるんだけど

596:デフォルトの名無しさん
09/06/26 11:17:34
俺も変更リストが空になってる。
ignore-on-commit使ってるのが悪いのかしら。

597:デフォルトの名無しさん
09/06/26 17:32:46
>>596
そのようだね。ignore-on-commitがあるとチェックが外れるみたいだ。

次ページ