Subversion r11 - 暇つぶし2ch

Subversion r11 ..

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があるとチェックが外れるみたいだ。

598:デフォルトの名無しさん
09/06/26 20:49:25
svn help XXX のメッセージが日本語と英語がかなり混在しているけど
日本語への翻訳はもうしていないの？

599:デフォルトの名無しさん
09/06/26 23:41:52
svnbookの1.6対応日本語版ﾏﾀﾞｰ?

600:デフォルトの名無しさん
09/06/27 01:43:00
>>589,>>592
1.3 の頃に作った300MB、リビジョン1400のリポジトリを 1.6 で dump/load したら
100MBぐらいになりました。
そこから更に dump したのを 1.3 で load したら元のサイズになったので、
中身が飛んだりはしてないらしいです。

作り直しが効果的だった例ということで。

601:デフォルトの名無しさん
09/06/28 12:18:41
レンタルファイルサーバのWebフォルダ(WebDAV)上にリポジトリを作成してそれをWindowsから使いたいんですが、
TortoiseSVNで右クリックしても「リポジトリを作成」が出てこなくて、一旦ローカルでリポジトリを
こさえてからエクスプローラでコピー、またはTortoiseSVNの再配置を使ってWebフォルダを指定しても
「リポジトリは恒久的に'http://～'へ移動しました。relocate(参照URLの変更)を実行してください。」
とエラーメッセージが出てきて先に進めないのですが、どうすればうまくいくのでしょうか？
普通にSambaファイルサーバ上のリポジトリにアクセスするのと同じようにはいかないのでしょうか？

602:デフォルトの名無しさん
09/06/29 00:29:24
>>598
subversion/po/ja.po のコミットログを見てもらえればわかるとおり、
訳してた人が1年以上動けてないみたい。
リアルな生活が忙しくてそれどころではないという噂を聞いたです。

>>599
svnbookの1.6対応版ってtrunkかなぁ
tag切られたら1.5には見切りを付けて、1.6にしようかと思ってるんだけど、
TortoiseSVNのマニュアルが滞っててそれどころでもなかったり。

603:589
09/06/29 00:31:21
>>592
>>600
ありがとうございます、全くの反対方向に理解してたことがよく分かりました。

とりあえず1.6.3を落としてきました。
先に教えてもらったページを読み込んでからバージョンアップに挑戦してみます。

604:デフォルトの名無しさん
09/06/29 01:46:11
>>601
普通はサーバ上で本家のSubversionを動かし、さらにそいつでレポジトリを作っておく。
そうしておいて、クライアント側からTortoiseSVNなどでチェックアウトするというのが素直なやり方だと思う。

605:デフォルトの名無しさん
09/06/29 11:52:27
知らないならレスしないでください

606:デフォルトの名無しさん
09/06/29 13:36:35
>>605
お前、もう誰からもまともなレスは付かないぞ。
さっさと知恵袋にでも逝けｗ

607:デフォルトの名無しさん
09/06/29 13:50:05
自分がどれだけアホな質問をしてるのか、それは数年後にわかるだろう

608:デフォルトの名無しさん
09/06/29 13:51:19
IDなしだから、605は私じゃありませんと言い出すんだよね

609:デフォルトの名無しさん
09/06/29 14:32:01
ていうか、>>605 みたいなレスをあちこちに投下してる愉快犯がいやがる。

610:デフォルトの名無しさん
09/06/29 14:41:58
OpenGLスレでも同じようなキチガイがいたな

611:デフォルトの名無しさん
09/06/29 14:50:45
IDなしの板で質問するのがアホ

612:601
09/06/29 19:58:15
>>605は本当に私じゃありません

613:デフォルトの名無しさん
09/06/30 05:07:41
> 知らないならレスしないでください
これはIDなし板での恒例のレスだろｗｗ

614:デフォルトの名無しさん
09/06/30 10:25:23
そういうレスを面白半分に投下する奴は人間の屑だと俺は思うが。

615:デフォルトの名無しさん
09/06/30 11:48:45
面白半分じゃなくてID推進活動の一環だろ。
質問はトリ付けることを推奨でいいんじゃね。
IDは変わりやすい人もいるからIDあってもトリ付いてた方がいいし。

616:デフォルトの名無しさん
09/06/30 11:53:12
2ちゃんねる的にはIDを付けなければならんほど、住人の民度が落ちた、
ということで、IDが付くのは、ある意味、終わったということなんだが。

そんなにム板を終わらせたい奴がいるわけ？

617:デフォルトの名無しさん
09/06/30 11:55:56
住民がどう以前に関係ないやつがおもしろ半分にあちらこちらで暴れてるんだからどうしようもないだろ

618:デフォルトの名無しさん
09/06/30 12:01:27
こんなの恒例なんだから、スルすればいいだけのことだよ

619:デフォルトの名無しさん
09/07/06 20:32:16
>>602
> tag切られたら1.5には見切りを付けて、1.6にしようかと思ってるんだけど、
URLﾘﾝｸ(svnbook.red-bean.com)
ここにある日本語版は1.5どころか、
> この本は Subversion バージョン管理システムのバージョン1.2系のために書かれたものです。
という記述 (URLﾘﾝｸ(subversion.bluegate.org)) があるとおり相当古いものです。
どこかに1.5相当のsvnbook日本語版が存在するのでしょうか?

620:デフォルトの名無しさん
09/07/06 20:36:38
「鍋太郎」氏のサイトのが1.5相当だったかと。

621:デフォルトの名無しさん
09/07/06 20:40:19
すっごい初歩的な質問なのですがMac OS X 10.5+Xcode 3.1+subversionな環境で

エラー：155007（Path is not a working copy directory）説明：'/path/to/hogehoge' is not a working copy

と出る場合はどうすればいいですか？

622:デフォルトの名無しさん
09/07/06 23:51:08
>>619-620
半分ぐらいしか訳せてなくて申し訳ないのだけれど。
一応リファレンスだけは訳したつもり。

623:デフォルトの名無しさん
09/07/07 13:31:07
>>621
「チェックアウトしたディレクトリではありません」ということです。
何をしたいのかによりますが、
チェックインしたいなら、先にチェックアウトしてみてください。

624:デフォルトの名無しさん
09/07/07 13:35:52
>>621
1. ローカルコピーを削除する。 (cd myxcodeproject; rm -rf . )
2. サーバーから”ビルド”フォルダを削除する
3. チェックアウトする (svn co URLﾘﾝｸ(svnserver) . )

参考：URLﾘﾝｸ(note19.com)

625:デフォルトの名無しさん
09/07/14 15:29:46
Subversionって管理者権限を持ってると変更履歴の改竄は可能ですか？

626:デフォルトの名無しさん
09/07/14 15:30:48
履歴とは何
ログなら可能

627:デフォルトの名無しさん
09/07/14 15:32:39
>>626
ログメッセージじゃなくログそのものですね
ｘｘというソースを追加したとか変更したとか

628:デフォルトの名無しさん
09/07/14 15:36:41
↑
いちいち余計なひとことで他人をムッとさせるタイプのひと。

ログ
ヒストリー
履歴

たしかに統一してほしいけど、読めばわかるだろ。

629:デフォルトの名無しさん
09/07/14 15:38:08
どう見てもお前さんのレスこそ他人をむっとさせるだろｗ

630:デフォルトの名無しさん
09/07/14 15:40:12
むっ

631:デフォルトの名無しさん
09/07/14 15:57:21
改竄だと
rev.NNNを無かったことにする
-rNNN:NNN+1 の差分を変更する
とかじゃないの？

632:デフォルトの名無しさん
09/07/14 20:34:57
むっ

633:デフォルトの名無しさん
09/07/15 03:55:22
>>631
そうです
あるリビジョンで追加したファイルがなぜか変更扱いになってたりとあとで
改竄できるのかなあと思いまして
当然追加を変更扱いするわけなのでもっと前のリビジョンで追加されてたことにするわけですが

634:デフォルトの名無しさん
09/07/15 07:51:16
なんで自分のやりたいことを具体的に説明できないのかねぇ。
まぁ、きちんと説明できるくらいなら自力で調べることもできそうではあるが。

635:デフォルトの名無しさん
09/07/15 08:13:19
>>633
聞いた限りでは、ただの勘違いにしか思えないな。

636:デフォルトの名無しさん
09/07/15 10:21:06
>>633
履歴の削除はできます。
削除した場所に別の履歴を入れたりは難しいです。

普通は履歴を改竄する必要はないはずです。
よっぽどのこと（顧客の個人情報をコミットしてしまった等）があった場合には、
その部分の履歴を削除することはありますが、
それ以外では、単に追加・更新していくだけで大丈夫なはずです。

637:デフォルトの名無しさん
09/07/15 17:17:38
ソフトウェアの情報を見ると
バージョン番号の次にリビジョン番号(1.2.3-r45678)がくるものがあるけど
C/C++のソースコードにsubversionのリビジョン番号をソースコードの中に組み込む事ってできるんですか？

638:デフォルトの名無しさん
09/07/15 17:19:37
何でドキュメントを読まないの？

639:デフォルトの名無しさん
09/07/15 17:29:08
オレのドキュメントは２ちゃん

640:デフォルトの名無しさん
09/07/15 17:44:57
>>637
svn:keywordsを設定してキーワード置換をすればできます。

たとえば属性svn:keywordsにRevisionを設定してから
ソース中で rev = "$Revision$"; などと書いておくと
チェックアウト時に実際のリビジョン番号に置換されます。

参照：URLﾘﾝｸ(subversion.bluegate.org)

641:デフォルトの名無しさん
09/07/15 20:17:25
>>637
その質問、すでに何度も出てるよ

642:デフォルトの名無しさん
09/07/15 20:25:01
>>637
過去ログで何回も出てるけど、
svn:keywords, svn info --xml, svnversion, subwcrev (TortoiseSVN)とか。

あと、継続的実行 (Continuous Integration。わからなければググレ）してるなら、そっちの機能でも出来たりすることがある。

643:デフォルトの名無しさん
09/07/17 19:20:27
TrutoriseSVNでsvn+sshで接続できなかったので初心者質問です。
前任の人が入れていったSubversionを利用したくて、Subversion初心者なりに頑張ったのですが
ダメでしたので質問です。

・前任者がパスフレーズと、「ssh_rsa.ppk」なるファイルを残していった
・Puttyではこのppkファイルとパスワードで接続できた
・TrutoriseSVNのネットワーク設定でこのppkファイルを食わせて、ユーザー名とパスフレーズを入れてもログインしてくれない

自分の環境はWindowsXP、TrutoriseSVN1.6.2
接続先はSubversion1.4.6
LinuxはRed Hat Enterprise Linux ES release 4 (Nahant Update 5)
と記述してありました。

Unix文化やセキュリティというものに親しんでこなかったので、何が悪いのか調べる方法に困っている状況です
お知恵を頂ければありがたいです

644:643
09/07/17 19:34:24
一応前任の方のメモ書きを参考にしたのですが、どうしてもパスフレーズを求められて
メモに書かれたものを入れてもログインできません。(Puttyだと通った)
・リポジトリブラウザに入れたパスの問題なのか
・パスフレーズの問題なのか
・それ以外なのか

ちょっとどれが有力なのかも自分の中で絞れない感じです

前任者のメモの要約です。

(miyaが前任者の名前)
【TortoiseSVNの設定】
・エクスプローラー上で右クリック→TortoiseSVNの設定→ネットワークを表示
・SSHクライアントのボックスに以下を入力
C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -l miya -i 秘密キーファイルのパス
・リポジトリブラウザで以下のURLにアクセス
svn+ssh//hostname/home/miya/svn/project/hogeprj/reps/trunk
(hogeprjがプロジェクト名)

よろしくお願いいたします

645:デフォルトの名無しさん
09/07/17 19:55:13
>>643
えっと、参考になるか分からないけど、自分の設定を晒しときます。

SSHクライアントはPutty付属のplinkw.exeを使って -batch オプションを付けてます。
で、接続する前にこれまたPutty付属のpageant.exeを起動して秘密キーを登録しておきます。
これでレポジトリにアクセスできてます。

646:デフォルトの名無しさん
09/07/17 19:56:23
>>643
puttyのパッケージに入っているplinkを使ってみてください。
puttyごった煮版に入っているplinkwがお勧めです。

TortoiseSVNのネットワーク設定のSSHクライアントに次のように入力します。
C:\Program Files\PuTTY\plinkw.exe

秘密キーはpageantに登録して使うと便利です。
詳しくは次のページを見てください。
URLﾘﾝｸ(www.sodan.ecc.u-tokyo.ac.jp)

647:645
09/07/17 19:57:58
追記。
レポジトリにアクセスするときにユーザ名を付けてます。
svn+ssh://user@host/svn/repo/trunk

648:デフォルトの名無しさん
09/07/17 20:05:10
subversionの環境を使いたいの？
それとも、リポジトリを使いたいの？

649:デフォルトの名無しさん
09/07/17 20:06:15
リポジトリを使いたいだけなら、がんばってサーバでリポジトリをダンプして、
windowsでインポートすればOK

650:デフォルトの名無しさん
09/07/17 22:58:44
複数案件を、検証用サーバ、本番サーバに順不同でリリースしたい場合の例ってどこかにありますか？

具体的には、検証用サーバには案件A Bの順でリリースしたが、
本番サーバには案件B Aの順でリリースしたい場合です。

現在のリポジトリ構成
trunk 検証、本番
branches
　案件A
　案件B
のような感じです。

651:デフォルトの名無しさん
09/07/17 23:07:45
「リリース」でSubversionで何をしたいのかがわからん

652:デフォルトの名無しさん
09/07/17 23:15:40
各サーバで普通にチェックアウトするだけじゃないのか

653:デフォルトの名無しさん
09/07/17 23:49:17
>>650
もう少し解りやすく質問してお願い。

654:650
09/07/18 01:58:14
言葉が足りずすみません。
既存システムの修正を行おうとしています。
修正の内容が2種類あり、それらのリリースタイミングが異なるため、別のブランチを作成します。
リリースはtrunkにマージしたものを本番サーバに配布することを指しています。
また、それぞれの案件が同じファイルを修正する可能性もあります。

検証用サーバを挟まない場合、
1 trunkをコピーして、A Bブランチを作成
2 (Aをリリース) Aをtrunkにマージ
3 (Bをリリース) trunkの変更をBにマージ後、Bをtrunkにマージ
という流れでいけると思っています。

しかし、検証用サーバを挟み、本番サーバへBを先にリリースしたい場合、
1 trunkをコピーして、A Bブランチを作成
2 (Aを検証用サーバにリリース) Aをtrunkにマージ
3 (Bを検証用サーバにリリース) trunkの変更をBにマージ後、Bをtrunkにマージ
4 (Bを本番サーバにリリース)
とやってしまうと、Bを先に本番サーバへリリースを行おうとした時に、BのブランチにはAの内容が
含まれた状態になっているため、Bのみの内容を抽出することが難しいのではないかと懸念しています。

伝わるでしょうか。。。

655:デフォルトの名無しさん
09/07/18 09:14:30
リリース直前に専用のブランチを作って、そこで切ったタグからリリースしてはどうでしょう。
リリース直前の修正はブランチで行い、trunkへのマージはタグ切ってリリースした後で。

そもそも、本番サーバへのリリース計画と異なる手順で検証用サーバにリリースするのが間違いのような。
いったい何を検証するつもりなんでしょうか？

656:デフォルトの名無しさん
09/07/18 10:06:40
>>654
なんでtrunkにマージすんだよ。
branchの先端をリリースしろ、馬鹿。

657:653
09/07/18 14:32:00
>>654　流れは大体合ってる。

>3 (Bを検証用サーバにリリース) trunkの変更をBにマージ後、Bをtrunkにマージ
ここの後半で競合が起きるかもってことかな？確かに起きる。
TortoiseSVNであれば、このときはBをtrunkにマージではなくって、ブランチを再統合するを選べばＯＫだよ。詳しくはtortoiseSVNのヘルプの4.20ブランチの再統合を参照してね。
尚、Bの変更内容だけを抽出したいなら、trunkの変更をBにマージした時点でのＢとtrunkとの差分をとればBの変更が抽出できる。

658:デフォルトの名無しさん
09/07/18 14:59:27
ありがとうございます。

>>655
確かに、同じファイルを変更する可能性があるため、後から検証サーバに配置したものについて、
厳密に検証が行えなくなることは認識しています。
専用のブランチというのは検証用サーバと同じ状態にあると見なすブランチということでしょうか？

>>656
Aブランチの先端をリリース、Bブランチの先端をリリースという順で行うと、同じファイルを変更した場合に
Aブランチの修正が消えてしまうのではないでしょうか。

>>657
競合が起きるのは仕方ないと思っています。TortoiseSVNの統合をもう少し見てみます。
Bの変更内容は確かにおっしゃる方法で抽出できると思うのですが、検証サーバでの修正を
どこにコミットすればいいのかが分かりません。
trunk(検証サーバの最新状態)に入れた場合、Bブランチに入れた場合ともに、Bのみの修正を抽出
しにくくなると思っています。

1 検証サーバの状態を保つためのブランチ(test)をtrunkから作成
2 (Aを検証サーバにリリース)
　　Aをtestにマージ
3 (Bを検証サーバにリリース)
　　Bから作業ブランチBsubを作成
　　Bsubにtestの変更をマージ
　　Bsubをtestにマージ
なども考えてみたのですが。。
もう少し考えてみます。

次ページ