[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 07/26 10:29 / Filesize : 191 KB / Number-of Response : 753
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Subversion r11



1 名前:デフォルトの名無しさん mailto:sage [2008/12/29(月) 03:25:58 ]
Subversionはフリーなオープンソースのバージョン管理システムです。

公式HP
subversion.tigris.org
subversion.tigris.org/

Subversion によるバージョン管理
subversion.bluegate.org/

subversion: Project Status
subversion.tigris.org/project_status.html

subversion: Subversion Links
subversion.tigris.org/links.html

Version Control Systems Comparison
better-scm.berlios.de/comparison/comparison.html

前スレ
r10 pc11.2ch.net/test/read.cgi/tech/1215565366/
r9 pc11.2ch.net/test/read.cgi/tech/1202086238/
r8 pc11.2ch.net/test/read.cgi/tech/1192864879/
r7 pc11.2ch.net/test/read.cgi/tech/1180858500/
06 pc11.2ch.net/test/read.cgi/tech/1165892754/
05 pc8.2ch.net/test/read.cgi/tech/1145841405/
04 pc8.2ch.net/test/read.cgi/tech/1129642894/
03 pc8.2ch.net/test/read.cgi/linux/1100622362/
02 pc5.2ch.net/test/read.cgi/linux/1078609142/
01 pc.2ch.net/test/read.cgi/linux/1002355536/

496 名前:デフォルトの名無しさん mailto:sage [2009/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 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 13:49:53 ]
>>496でダブルクォーテーションの括り方がおかしかった、スマソ。

498 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 15:19:53 ]
>>496
ありがとう!

それらのキーワードでぐぐったら、けっこうドキュメントがでてきました。
svnserve, 専用サーバ
subversion.bluegate.org/doc/ch06s03.html

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

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


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

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

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

501 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 19:32:52 ]
>>500
そう、別鍵を用意する。

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

503 名前:デフォルトの名無しさん mailto:sage [2009/06/01(月) 12:27:14 ]
>>502
Subversiveは捨てて、Subclipseに移ればいいよ。
SubclipseはSubversion1.6に対応している。
ttp://subclipse.tigris.org/

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



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

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

507 名前:デフォルトの名無しさん mailto:sage [2009/06/03(水) 11:04:16 ]
SVK の代わりに何を使えばいいの?
lists.bestpractical.com/pipermail/svk-devel/2009-May/001224.html


508 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 03:12:57 ]
>>507
今年中にはbzr-svnが実用レベルになる。

509 名前:デフォルトの名無しさん mailto:sage [2009/06/05(金) 06:04:56 ]
bzrはやるやる詐欺

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

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

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

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

513 名前:デフォルトの名無しさん mailto:sage [2009/06/06(土) 00:19:06 ]
>>512
何のリポジトリっすかww

514 名前:デフォルトの名無しさん mailto:sage [2009/06/06(土) 00:28:57 ]
>>512
画像や音声データが入ってるな。ゲームの開発か?



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

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

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

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

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

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

519 名前:デフォルトの名無しさん mailto:sage [2009/06/06(土) 19:21:22 ]
6年分とか怖くて出来ないな…。

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

デブサミ2009「株式会社はてなの開発戦略」講演メモ - RX-7乗りの適当な日々
d.hatena.ne.jp/rx7/20090212/p1


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

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

522 名前:デフォルトの名無しさん mailto:sage [2009/06/06(土) 20:56:51 ]
使い始めてまもないんだけど
時々壊れるものなん?

523 名前:デフォルトの名無しさん mailto:sage [2009/06/06(土) 21:30:45 ]
どんなツールでも壊れることはあるよ
俺はCVSとVSSでも壊れたの見たことある

524 名前:デフォルトの名無しさん mailto:sage [2009/06/06(土) 21:35:39 ]
>>520みたいにHDDが壊れたとかはsvnのせいじゃないしなあ。

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



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

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

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

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

528 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 06:23:41 ]
わかってねぇな

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


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

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

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

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

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

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

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

533 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 16:33:00 ]
>>527
ネタにもなってないし、言い回しは腐ってるしw

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



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

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

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

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

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

540 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 18:14:31 ]
実際にやっているから言っているんだが。何がどう難しいか言ってみろ。

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

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

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

544 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 18:35:29 ]
流れからしてsageてないやつが犯人



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

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

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

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

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

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

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

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

553 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 18:51:18 ]
>>551
意味ないでしょそれ比較しても
本当にdumpしてる?

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



555 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 18:54:00 ]
>>553
だからどう意味が無いんだ?

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

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

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


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

558 名前:名無し募集中。。。 [2009/06/07(日) 19:12:03 ]
なんかもう人格否定じゃん

559 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 19:16:39 ]
どこが人格否定なんだよ

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

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

562 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 19:37:41 ]
人のやり方を否定するより、

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

って書いて欲しい

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

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



565 名前:デフォルトの名無しさん mailto:sage [2009/06/07(日) 20:22:39 ]
dumpは運用としては現実的じゃないよね

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

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

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

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

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

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

・・・で、合ってる?

571 名前:デフォルトの名無しさん mailto:sage [2009/06/08(月) 05:26:56 ]
subversionを捨てればいいんじゃないか、

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

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


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

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



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

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

577 名前:デフォルトの名無しさん mailto:sage [2009/06/15(月) 17:55:53 ]
svn のバージョンアップに強いのは dump? or hotcopy?


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

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

580 名前:デフォルトの名無しさん [2009/06/17(水) 17:11:30 ]
subversionの運用について教えてください。

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

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

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

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

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

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

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

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

それが俺ルール。


584 名前:デフォルトの名無しさん mailto:sage [2009/06/18(木) 11:16:40 ]
リポジトリ vs レポジトリ 論争がまた始まりそうな予感



585 名前:デフォルトの名無しさん mailto:sage [2009/06/18(木) 11:26:13 ]
あろうようにする

586 名前:デフォルトの名無しさん [2009/06/21(日) 23:50:40 ]
TortoiseSVN 1.6.3 age
https://sourceforge.net/project/shownotes.php?release_id=691197

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

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

589 名前:デフォルトの名無しさん mailto:sage [2009/06/23(火) 03:59:50 ]
ちと質問。

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

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

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

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

590 名前:デフォルトの名無しさん mailto:sage [2009/06/23(火) 04:42:10 ]
>>587
TortoiseSVN の開発チームは Subversion 開発チームとはまったく別。

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

591 名前:デフォルトの名無しさん mailto:sage [2009/06/23(火) 04:44:06 ]
>>588
実測しないとなんとも。

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

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

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

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

詳しくはこちら。っていうかこっち先に読めよ。
subversion.tigris.org/svn_1.6_releasenotes.html#compatibility

593 名前:デフォルトの名無しさん mailto:sage [2009/06/23(火) 21:58:17 ]
>>338 >>472の件、ようやく本家で対応されますた

Version 1.6.3
(19 Jun 2009, from /branches/1.6.x)
svn.collab.net/repos/svn/tags/1.6.3

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 名前:デフォルトの名無しさん mailto:sage [2009/06/25(木) 10:57:48 ]
Version 1.6.3
ttp://sourceforge.net/project/shownotes.php?release_id=691197



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



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

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






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<191KB

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