Subversion r9 - 暇つぶし2ch

Subversion r9 ..

462:デフォルトの名無しさん
08/03/24 20:59:06
>>459
便利なのにと言葉をこぼす程度なら誰もタイムスタンプ信仰なんて言わないよ。
そりゃ出来るに越したことはないんだし。
タイムスタンプが復元されないから糞だと
暴れてるキ印に対してそう呼んでるだけ。

463:デフォルトの名無しさん
08/03/24 21:02:28
クライアントがいじったファイルって変更時間は実際にシステム上で変更した時間のほうが良くない?
タイムゾーン違うとかでローカル時間より先のファイルが出来ているのは気持ち悪い。

464:デフォルトの名無しさん
08/03/24 21:03:40
何言ってんだお前

465:デフォルトの名無しさん
08/03/24 21:04:16
何言ってんだお前

466:デフォルトの名無しさん
08/03/24 21:19:52
タイムゾーンは関係ないだろ・・・

467:デフォルトの名無しさん
08/03/24 21:31:38
>>463
MAKEで使うなら、さっき変更したファイルより今変更したファイルのほうが新しいことが判れば問題ない。

468:デフォルトの名無しさん
08/03/24 21:34:17
未来のファイルだと困るけどな

469:デフォルトの名無しさん
08/03/24 23:59:38
なんだをぃ、盛り上がってるな。

make を例に挙げて*NIXの方がタイムスタンプ信仰強いなんて言ってるやつは、
時刻と時間の区別がついてないんじゃねーか?

470:デフォルトの名無しさん
08/03/25 00:24:42
時間に何の関係が？

471:デフォルトの名無しさん
08/03/25 06:01:47
>>469
何見当違いのこと言ってるんだ？
誰もそんな話してない．

472:デフォルトの名無しさん
08/03/25 07:05:53
前から思ってるんだけどさ、

履歴付きコピーで追加したときはコピー元の URL とリビジョンが情報としてくっつくよね。
それと同じように、ふつうの（履歴付きじゃない）追加のときに元ファイルのタイムスタンプを
情報としてくっつけとけばいいと思うんだ。

そんで、 export とか use-commit-time のとき、ふつうに追加された後、変更が一度も
かかっていないファイルに限って、保存してあるタイムスタンプを使うの。

思ってるだけじゃなくて、実装してみればいいんだろうけどね。面倒なのもあって
なかなか試せていない。

本当に本当に「インポート→エクスポート」でタイムスタンプが保持されるべきだと強く
信じている人がいるなら、だれかこいつを実装してみてほしい。

473:デフォルトの名無しさん
08/03/25 07:21:18
はじめてこの流れに乗るけど、タイムスタンプは欲しいと
思ったことが無いし、後々不都合になりそう。
SVNでディレクトリが管理対象であることが不都合
なのと同じ。

474:デフォルトの名無しさん
08/03/25 08:50:08
タイムスタンプ自体は保持されてるんだから、
インポートした時のタイムスタンプが残るようにしろって考えは
そんなに不自然なものだとは思わないけど。

いや、別に俺はどっちでもいいんだけどさ。
なんでこんなに否定されまくってんだ？

475:デフォルトの名無しさん
08/03/25 09:59:54
>>472
> 本当に本当に「インポート→エクスポート」でタイムスタンプが保持されるべきだと強く
> 信じている人がいるなら、だれかこいつを実装してみてほしい。

いや、べきだと信じてるわけじゃなくて、実際にそういう要求があるんです。納品のときとかに。

476:デフォルトの名無しさん
08/03/25 10:32:22
それは Subversion で管理すべきことなの?

477:デフォルトの名無しさん
08/03/25 10:35:55
要求があるのは分かる
だが現実には保持されていない
保持されていないなら、されていないなりの使い方をするしかない
でもそれを発言すると相手の反論はSVNは糞だって逆ギレされるだけなんだよ
結論はとっくに出てる
でもしつこく繰り返す
だからタイムスタンプ信仰なんて言われんの

478:デフォルトの名無しさん
08/03/25 10:50:14
>>475
理由が実際の要求なら、もう何も迷うことはないな。やってみてくれ。

479:474
08/03/25 10:51:09
いま調べてみたんだけど、タイムスタンプってリビジョン毎に付くんだね。
個別のファイル毎のタイムスタンプを残してるわけじゃないから、
現状の仕様だと Subversion だけで何とかするのは無理だと思う。

cvs2svn みたいな、インポートを実行してくれる外部ツールを作るのが良さそうだね。

480:デフォルトの名無しさん
08/03/25 10:52:49
>>479
それ↑の方で何度も言われてる事なんですが・・。

481:デフォルトの名無しさん
08/03/25 10:53:58
>>479
>>443

482:デフォルトの名無しさん
08/03/25 11:01:54
>>479
実現するならエクスポート側だろ

483:デフォルトの名無しさん
08/03/25 11:09:28
元々makeの文化なんだから、import/commitしたファイルのタイムスタンプじゃ
*困るんだ* っていう人達が作った、んだよね？何こんな簡単なことでグダグダ
やってるんだ？

import/commit時にsvn:original-timestampを記録して、
export時にだけoptionalにそれを復元する、という仕様が良さそうな気もする。

484:デフォルトの名無しさん
08/03/25 11:13:49
だからいつまで続けるんだよ・・。

485:デフォルトの名無しさん
08/03/25 12:21:52
ソース管理下におかれない納品したファイルのバージョンを確認するのにタイムスタンプが欲しいから、
最終変更時刻かコミット時刻をエクスポート時に打ちたいんだけど何かいい方法ない？
とか質問すればすぐ解決したんじゃないか？
いきなり糞とか言うからもめるんじゃないかな。

486:デフォルトの名無しさん
08/03/25 12:35:03
ところで TortoiseSVN でクライアント側で
フック以外にもうちょっと細かい挙動を
いじれるようなプラグインって使えないの？

ファイル単位で呼び出されるようなコールバック
設定できるようだと、そこで何でもやれそうなんだが

487:デフォルトの名無しさん
08/03/25 12:39:29
>>486
1.5 から追加される「クライアント側フックスクリプト」でいける？
URLﾘﾝｸ(tortoisesvn.net)

488:デフォルトの名無しさん
08/03/25 12:56:42
>>476,478
やってます（>>429）。
ただ、そういう機能がsvnに実装されればうれしいなぁってだけです。

489:デフォルトの名無しさん
08/03/25 13:00:44
了

490:デフォルトの名無しさん
08/03/25 14:01:53
>>487
がんばればいける。
でもこれってグローバルなスクリプトなんだよね。
それがちょっといやだな、ってのが一点。

あと、どうせ TortoiseSVN なら Windows べったり
なわけで、DLL にコールバック関数用意するから
呼んでくれよ、ってのが本音。

491:デフォルトの名無しさん
08/03/25 14:29:23
eSVNを使おうと思ってesvn-0.6.12-1.tar.gzをダウンロードしたのですけれどもexeファイルがどこにも入っていません。どのように起動すればいいのでしょう？

492:デフォルトの名無しさん
08/03/25 15:48:27
>>487
export時のhookはどれなんだろう

493:デフォルトの名無しさん
08/03/25 17:40:09
タイムスタンプには、午前３時とか正月とか涙を誘うものがあるな。

494:デフォルトの名無しさん
08/03/25 23:09:44
とりあえずタイムスタンプ厨が粘着質なのはわかった

495:デフォルトの名無しさん
08/03/26 10:10:17
アンチの方も似たようなもん

496:デフォルトの名無しさん
08/03/26 21:39:08
初歩的な質問ですみませんが、
authorの名前を変更することはできますか？
ちなみにXP SP2でSubversion、TortoiseSVNの両方を使用しています。
XPではアカウントの名前が自動的にauthorの名前になるようですが。
よろしくお願いします。

497:デフォルトの名無しさん
08/03/27 01:29:01
>>496
コミット済みのやつを変えたいなら TortoiseSVN のログダイアログから変えられる。
ただしリポジトリに pre-revprop-change のフックを置く必要がある。

アカウントと別の名前で file://～なリポジトリにコミットしたいってことなら、
コマンドラインの svn なら --username で指定できる。 TortoiseSVN では、
たぶんできない。 svnserve を動かして svn://localhost/～とかいう感じにして、
passwd に適当な名前をつくればいいかもしれない。

498:デフォルトの名無しさん
08/03/27 02:22:56
初歩的な質問って自覚があるならちょっとは調べろよな・・
基本中の基本だしちょっと調べればすぐ分かるのに

499:デフォルトの名無しさん
08/03/27 02:40:27
>>495
タイムスタンプに安置とかwww
馬鹿が一人騒いでるのに過剰反応してるだけだろwww

500:デフォルトの名無しさん
08/03/30 22:04:46
.svn以下の不要なログファイルを消して
ワーキングコピーを軽くするにはどうしたらいいでしょうか？

501:デフォルトの名無しさん
08/03/30 22:34:53
>>500 svn cleanup かな？

502:デフォルトの名無しさん
08/04/01 08:48:09
余りにアホな質問で申し訳ないんですけど
同じソフトウェアのバージョン違いを管理する場合は
それぞれ別のリポジトリを作成して
別に管理するのが普通ですよね？

503:デフォルトの名無しさん
08/04/01 08:58:21
>>502
svn的にはsvn copyが普通。
むしろ別のリポジトリを作成する方がアホと言える。

504:デフォルトの名無しさん
08/04/01 11:04:51
出だしに初心者、あほな質問ってつけりゃ
良いってもんじゃねえぞ
少しは調べろ

ブランチ作るのが普通

505:デフォルトの名無しさん
08/04/01 11:37:12
>>502
以下サイトで公開してくれている
URLﾘﾝｸ(psyto.s26.xrea.com)

svnbook日本語訳のPDF版の第４章を読みなさい

506:デフォルトの名無しさん
08/04/02 01:16:19
>>503-505
ありがとうございます
>>505 さんの出したくれたリンク先のPDF一通り読んでみます

507:496
08/04/03 18:11:42
>>497
亀レスですみません。
ありがとうございました。
助かりました。

>>498
ググるの下手みたいで、すみません。
こちらも練習します。

508:デフォルトの名無しさん
08/04/05 21:39:40
ローカルのリポジトリなら都度のコマンドだけで使える！
一人で使うのに別マシンでサーバー常駐させてた私の数年…。

509:デフォルトの名無しさん
08/04/05 22:02:15
別マシンじゃなくて同一マシンで動かせばよかったんじゃ

510:デフォルトの名無しさん
08/04/05 22:24:19
>>508
片方のPCのHDD死んでもソースが完全に死なないから冗長性あっていいんじゃ？

511:デフォルトの名無しさん
08/04/10 20:03:56
それならリポジトリミラーリングした方が100倍ましだろ

512:デフォルトの名無しさん
08/04/11 15:03:44
TortoiseSVN使ってるんだけど、最初のチェックアウトとかの時にやたらフリーズする。
OS丸ごと固まって電源おすしかないように。
チェックアウトして、ファイルのログが流れてる途中でいきなり止まる感じ。
前まではそんなことなくて、最近新しいプロジェクトので新規に作ったらそうなった。
ファイル数がかなり多いんだけど、それは関係あるんだろうか？

最新版なんだけど、みんな普通に使えてる？

513:デフォルトの名無しさん
08/04/11 15:13:48
もしかして、アイコンオーバライドの更新で填まるのかな?
Geodeで使っている最新版ではアイコンオーバライドすると死ぬほど時間掛かるからオーバライドを止めちゃったけど。

514:デフォルトの名無しさん
08/04/13 00:37:48
URLﾘﾝｸ(www.exacteye.com)
など見るとcommitとupdateは別の処理だとありますが、
commitとupdateのタイミングをどう取っていくべきか、
まだ使い慣れてないせいか、いまいち直感的に理解できません。

自分一人しかレポジトリいじらない場合は
updateせずにcommitだけやり続けても問題ないですか？
ファイル名をかえたり削除したりする時はupdateも必要？

515:デフォルトの名無しさん
08/04/13 01:28:36
テストリポジトリとその作業コピーを２つ作って、
同じファイルを修正して、両方を順番にコミットしてみればいいぜ
どういう反応を示すかわかる。

一人の場合、基本コンフリクトは発生しないので update いらんでしょ

516:デフォルトの名無しさん
08/04/13 08:47:52
んにゃ、一人でも開発拠点が複数だとupdateは必要だぞ。
Conflict発生はまずないけど。

517:デフォルトの名無しさん
08/04/13 10:50:36
>516

同じバグを一人で3度修正してconflictさせたバカがここにいる。

「あれ～直さなかったっけこれ？夢でも見たかな...」

% svn commit
C fugahoge.c

Σ(゜Д゜;)

518:デフォルトの名無しさん
08/04/13 13:00:15
>>517
あれ？、俺こんなの投稿したっけ？

519:デフォルトの名無しさん
08/04/13 13:37:17
Subversionを大いに役立てている>517-518にちょっと嫉妬。

520:デフォルトの名無しさん
08/04/16 00:21:02
すみません、smartsvnについて解説しているページとかないでしょうか？
日本語化パッチもないようですし・・・。

521:デフォルトの名無しさん
08/04/16 04:21:37
初めて聞いた

522:デフォルトの名無しさん
08/04/16 23:31:47
説明して目の前でコミットして見せてやったのに削除→コミット→追加→コミットしやがった。
家では使ってるとか言ってたくせに・・・
こんな奴が技術者とか・・・ﾏｼﾞ怖いよ

523:デフォルトの名無しさん
08/04/17 00:06:07
>>522
そういうの使ってるって言わないよなｗ

524:デフォルトの名無しさん
08/04/17 00:25:42
うちの場合、間違った使い方をしたらコミットを失敗させてアドバイスを
表示するようにしている。

525:デフォルトの名無しさん
08/04/17 01:49:56
すげぇ　ハイレベルだな。

526:デフォルトの名無しさん
08/04/17 02:42:23
>>524
それって，具体的にはどうやるの？
「間違った使い方」の判定とかかなり気になるんだが

527:デフォルトの名無しさん
08/04/17 10:04:23
あの、 - で始まるファイル名に変更したいときってどうすりゃいいんでしょうか。
まぁほとんど無いことかとは思うんですが、hoge ふぁいるを -hoge ファイルに
したいのです。svn rename hoge -hoge　だと -hoge なんてオプションねぇよ氏ね
って言われるし・・・死にたくない。

528:デフォルトの名無しさん
08/04/17 10:20:51
>>527
エスケープじぇだめなんだっけ?
試してないけど。

529:デフォルトの名無しさん
08/04/17 10:30:35
そういや touch で - とか -- とか --- とか -_- とかいうファイル名って
作れるんだったっけ？いや、いろいろ挙動をテストしようと思って
なんかはまってる。本来業務と違うところで。

530:デフォルトの名無しさん
08/04/17 11:11:34
touchは知らんが、

% svn mv -- hoge -hoge
A -hoge
D hoge

531:デフォルトの名無しさん
08/04/17 11:13:11
コマンドラインの解釈は各コマンドによるけど、 -- の後ろの引数は - や -- で始まっていても
ファイル名として解釈するという仕様のものが多い。

touch -- --
rm -- --

532:デフォルトの名無しさん
08/04/17 11:29:01
win版 1.4.6 で確認。
svn rename hoge .\-hoge

533:デフォルトの名無しさん
08/04/17 14:08:29
>>526
pre-commit フックのときに Subversion API と SQLite3 を使ってあれこれ調べています。
検査項目は過去4年間の「困った使い方」の記録をもとに決めているので沢山あり、今でも
増え続けています。もちろんそれぞれの検査項目には検査を迂回する手順を用意しています
が、迂回は1万数千リビジョン中に 3, 4 回ぐらいしか使われていません。

初心者の間違いで一番多いのは svn copy や svn move を使うべきところを新規ファイルの
追加にしてしまうところです。この操作の判定には苦労しました。

534:デフォルトの名無しさん
08/04/17 14:11:38
そのフックスクリプトすごいな。subversionのcontribに入れてもらえたらみんな幸せに…

535:デフォルトの名無しさん
08/04/17 16:11:15
どんな事してるのか、非常に興味深い。

536:デフォルトの名無しさん
08/04/17 16:24:29
コミットに時間がかかりそうっていうか邪魔くさそう

537:デフォルトの名無しさん
08/04/18 00:07:15
>>533
>>534がいい事を思いついたようだぞ

538:デフォルトの名無しさん
08/04/18 13:23:29
ignore_on_commit って何処に設定するんですか？
TortoiseSVN 1.4.8 を使用していますが、
もしかして、TortoiseSVN 1.5　からの機能ですか？

539:デフォルトの名無しさん
08/04/18 17:34:00
>>538
便利そうな属性だが、ググっても0件なんでがっかり。

540:デフォルトの名無しさん
08/04/18 18:01:26
Win な環境で、svn管理下のファイルをＯＳ削除したとき
コマンド操作で削除コミットしたい。
もちろん、管理下には修正ファイル、フォルダ、新規追加のファイル、フォルダが混在する。
上記作業を自動で行うために、フォルダツリーに散在した、削除フォルダ、ファイルを見極め
自動で削除コミットしたい。

IDEによる自動生成ファイルが多すぎる。
開くだけで、変更されるファイルがある。
実行するだけで変更されるファイルがある。

コミット・ファイルを見極めてコミットするだけで結構な時間を要してしまう。

そこで

サーバにひとつのワーキングコピーを配し、これを共有公開する。
作業者は、ファイル共有されたワーキングコピー上で直接作業する。
しかし、作業者はコミット等は実施しない。
コミットは、バッチ処理で、その日の作業分としてコミットする。

なにか、ヒント頂けないでしょうか？

541:デフォルトの名無しさん
08/04/18 19:05:29
>>540
なんだかよくわからんけど
管理する必要のないファイルを svn:ignore プロパティに
設定するってのではダメなの？

542:デフォルトの名無しさん
08/04/18 22:40:25
>>540
コミットは作業ごとに小刻みにやったほうがいいよ。
バージョン管理が必要なファイルだけ追加しておけば何も困る必要がない。
掃除はフォルダ丸ごと削除後にチェックアウトでもいいし。
もしVSなら、不要な中間ファイルはフォルダにまとめられてるし。プロジェクト関係で不要なのは、少しだけだし。一回作ってしまえば簡単なものじゃないかな。
もう少し楽に使うぜ。

543:デフォルトの名無しさん
08/04/19 00:08:54
ignoreは最初に誰もが通る道であろうに、
マニュアルではプロパティの1つって感じで扱ってるよなぁ。

544:デフォルトの名無しさん
08/04/19 03:52:37
>>540
> サーバにひとつのワーキングコピーを配し、これを共有公開する。
> 作業者は、ファイル共有されたワーキングコピー上で直接作業する。
それ、バージョン管理システム使ってるメリット無いお。
地獄への道一直線。# 昔CVSでそれをやられて酷い目にあった。

545:デフォルトの名無しさん
08/04/19 05:34:39
>>533
すげーなｗ

546:デフォルトの名無しさん
08/04/19 16:39:58
エディタ上で過去ソースとの差分が見れるようなソフトが欲しい。

常に見えてるのは最新のソースで、C#のregionみたいな感じで過去ソースが
展開できたりツールチップで表示できたりしたら便利そう。

547:デフォルトの名無しさん
08/04/19 19:37:42
マウスオーバーだけでは特定の過去ソースバージョンを指定するのは難しいからインターフェイスを考えないといかんな。

ツールチップでなければ、
TextMateのSubversionバンドルでは任意のリビジョン間のdiffを実行できた。
Emacsも間違いなくできるはず。
Eclipseもできるよな。

548:540
08/04/19 23:33:11
>>541 >>542 >>543 >>544
日本語でおｋって感じの文章に回答してくれて、ありがとうございます。

もちろん svn:ignore は使用しているのですが・・・

VS だけを使っているのなら、まだなんとかなるのですが・・・
他のツールも併用していて、そこから　ポコポコ大量の自動生成が・・・
VS のビルドもそう（？）ですが、あれって生成時の日付をどこかに埋め込むんですか？
内容は何も変わってないのに、生成するだけで変更になってしまいますよね？
まぁ　いろいろ書きたい事はあるのですが

俺も含めて、作業者のRCSの使いこなしが出来ていないと言うことで自分に言い聞かせてます。

でも、せめて安全なバックアップとして svn を利用しようと、また近い将来にそのリポジトリを
RCSの理念の基に利用できるようにするためにも、日々の作業分だけでもコミットしておこうかな
と思ったんです。

svn add *
svn commit -m "？？月？？日分"
で　追加・修正分は簡単にできるんですが
削除されたもの TortoiseSVN 上では「紛失」にあたるものの扱いがコマンドベースで
上手く処理する術を思いつきません。

というのが　本題です
長文スマソ　でした

549:デフォルトの名無しさん
08/04/20 15:42:07
すんごい、恥ずかしくて聞きにくいんですが、
svnのコミットログって一行でかかないといけないんでしょうか？

TortoiseSVNで複数行入力できるのですが、非推奨なのかな？

CodeReposのログとか見てると、みんな一行っぽいのですが・・・。

550:デフォルトの名無しさん
08/04/20 15:48:50
TortoiseSVNを使うか使わないかに限らず複数行書く私が来ましたよ。
コマンドラインでコメントを書く人は、複数行書くのが難しいから一行なのでは?

551:デフォルトの名無しさん
08/04/20 16:28:19
俺も恥ずかしい質問します！
自分は Subversion しか使ったことがないんですが、
他のバージョン管理ツール（たとえばCVS）から
移行するときに更新履歴やログも引き継げるものなんでしょうか？

バージョン管理ツールごとにポリシー（たとえばディレクトリに
リビジョンをつけるのか、ファイルごとにつけるのか）などが
異なるので引き継げないように思うのですが。

皆さん以降の際には HEAD だけ import して気分一新！
という感じなんでしょうか？

552:デフォルトの名無しさん
08/04/20 18:00:20
そりゃ完全さと効率を天秤にかけるもんだろう

553:デフォルトの名無しさん
08/04/20 18:01:12
CVSとVSSの移行ツールは見たことある。他も探せばあるかもしれない。

どれも履歴と更新ログくらいは対応してるだろうけど、実際に上手く行くかどうかは、試しにやってみないとなんとも言えない。
(海外の作者が作った移行ツールで、ファイル名や更新ログに漢字を使ったリポジトリを移行する場合とか)

554:デフォルトの名無しさん
08/04/20 18:03:16
>>549,550
俺も複数行書いてるっす。
コマンドラインにコミットメッセージを書かずにエディタで書いてる。

>>551
あんまり移行をしないけど、履歴は引き継げるはず。

ところでTortoiseSVNのchmヘルプの文字化けを解消するパッチを投げました。
1.5からはキーワードや検索が役に立つと思います。

555:デフォルトの名無しさん
08/04/20 18:13:45
>> 550 >>554
複数行やってる人いて安心した！

>>551
cvs2svnとか使ってみたけど、100くらいのリビジョンあるプロジェクトでやってみたら
何時間待っても終わらなかった覚えがｗ

結局、一新してimportし直したよ

556:デフォルトの名無しさん
08/04/20 18:21:05
Mercurialだったかな。
コミットログの1行目をサマリーとみなすという慣習があるのは。
この場合、詳細を2行目以降に書く。

557:デフォルトの名無しさん
08/04/20 18:22:57
CVSからSVNに移行した私が来ましたよ。
CVS2SVNなるスクリプトがあるので、移行するだけなら割と簡単にできる。
但し、リビジョン番号の振り方がCVSの概念を反映しきれないので過去の資産を活用するのは若干難しい。

例えば、コミット処理に時間がかかってコミット時間がずれてしまったような場合、別のリビジョンと解釈されかねない。
また、ブランチを作るときに一部のファイルだけしかブランチに入らなかった場合、SVN上は
一旦ブランチへのコピーを行なってから残りのファイルを全て削除したような履歴になってしまう。
# このため、コメントを伴わない(CVS2SVNが生成するコメントがついた)リビジョンが発生する。

558:デフォルトの名無しさん
08/04/21 01:28:55
>555
複数行でもいいけど、
コミットログ一覧では一行しか表示しないクライアントソフトが多いので、
1行で簡潔にまとめるのがいいと思う。

最低でも、1行目は概要、2行目以降に詳細とするべきかと。

559:デフォルトの名無しさん
08/04/21 03:56:01
自分も1行目をサマリーにしてます。
メールやTrac TimelineのRSSやEclipse (Historyビュー)、TortoiseSVNが
見やくなるので。
詳細は2行め以降、あるいはTracのチケットの方に書いてます。

560:デフォルトの名無しさん
08/04/21 06:12:58
hot-backupに掛かる時間て、リビジョン数に対して非線形に増加しない？
16000位で6時間以上掛かってる。5000の時は1時間位だった気がするのに。
いい方法ない？（dumpはおいといて）

561:デフォルトの名無しさん
08/04/21 12:25:37
>>560
ファイルコピーが遅いだけとか？試しに普通のファイルコピーしてみたらどうなるかな

562:デフォルトの名無しさん
08/04/21 12:38:03
>>548
> svn add *
これをやったら svn:ignore を設定する意味ないんじゃない？
svn:ignore は管理下にないファイルの存在警告を抑制するものであって、
add されるのを回避するためのものじゃない。
これでは作業ファイル等の不要なファイルまでリポジトリに追加されるよ。

>>542氏が言ってるように
> バージョン管理が必要なファイルだけ追加しておけば何も困る必要がない。
なので、管理が必要なものだけをリポジトリに追加していけばすっきりとした
運用ができると思う。

563:デフォルトの名無しさん
08/04/21 22:58:12
>>562
重箱の隅つつきみたいで悪いが、
* にディレクトリが含まれるとき、そのディレクトリの下は svn:ignore に従う。
svn:ignore を無視させて何が何でも無理矢理全部再帰的に add したけりゃ --no-ignore をつける。

564:デフォルトの名無しさん
08/04/22 03:05:21
>>561
ディスクはネットワークの先だから確かに遅い。
でも気にしてるのは、リビジョン数は3倍なのに時間が6倍になってる事。
これが納得いかない。

でかいリポジトリのhot-copyは諦めるしかない？

565:デフォルトの名無しさん
08/04/22 09:07:57
>>564
普通のファイルコピーでは6倍にならないことを確かめたの？

566:562
08/04/22 11:43:00
>>563
ディレクトリのことまで考えていなかったわ。
ディレクトリが含まれている場合の add の挙動について勉強になったよ。
レスありがと。

567:デフォルトの名無しさん
08/04/23 01:01:24
svn1.4 apache2.0 windows2003serverな構成でサーバを構築しています。
ディレクトリ単位でのアクセス制限も設定しているのですが、windowsだからなのか、リポジトリURL表記の大文字・小文字の扱いで悩んでいます。
ファイルシステム上のリポジトリがHOGEだったりするばあい、URLﾘﾝｸ(server)とかでもチェックアウト出来るくせに、
これでチェックアウトした場合、コミットが出来ません。当然、URLﾘﾝｸ(server)でチェックアウトすればコミットできるんですが・・・

で、リポジトリ名の大文字・小文字を間違える輩が大杉なんで、どちらでもコミットできる、あるいは、正しいリポジトリ名でなければチェックアウトできない、
と行った具合に、どちらかに統一したいのですが、解決策が見つからず、悩んでいます。

VisualSVNServerで環境構築したサーバでは、apache2.2ベースという違いはあれど、大文字・小文字が入り乱れていてもコミットできるのですが、
httpd.confを参考に当方のサーバのhttpd.confをいじってみても解決せず。

どなたか解決策をご教示いただけませんか？

568:デフォルトの名無しさん
08/04/23 01:22:27
Linuxに乗り換える

569:デフォルトの名無しさん
08/04/23 01:25:27
フックでチェックさせれば良いんじゃ

つうかそう言う大文字小文字を意識しないってのを
意識改革させないと、後で苦労するぞ

570:デフォルトの名無しさん
08/04/23 11:50:19
Windows上での開発だと大文字小文字の区別をしないのは普通かと。
Visual Studioがファイル名の大文字小文字があっていないテンプレートを平気で作るし。

うちはsvnserve運用だけど普通にコミットできる。
解決策になってないけど

571:デフォルトの名無しさん
08/04/23 12:32:45
使ったことないが
URLﾘﾝｸ(subversion.tigris.org)
に、
case-insensitive.py (contrib/hook-scripts)
pre-commit hook to detect case-insensitive filename clashes.
This is *much* more efficient than check-case-insensitive.py but it does require Subversion 1.3.0 or later.
ってのがあるよ

572:デフォルトの名無しさん
08/04/23 12:45:06
Windowsがどうであれ、SVNのリポジトリはLinux向けで識別するんだから
ファイル名の大文字小文字は意識するようにさせるべき

大文字小文字が違うだけのファイルがコミットされたら
Windows環境でチェックアウトするとAbortされるぞ

573:デフォルトの名無しさん
08/04/23 16:07:22
>>570はWindowsのクライアント
>>572はlinuxクライアントを想定してるんじゃないか？
>>567にはサーバー側のことしか書いてないし。

>大文字小文字が違うだけのファイルがコミットされたら
というのがまずあり得ない重箱の隅に聞こえる。
同じフォルダに大文字小文字が違うだけの同名ファイルをおくのはlinuxだと普通なのか？

574:デフォルトの名無しさん
08/04/23 16:27:53
むしろcaseを区別しないwindowsユーザー、アプリ側で
大文字小文字をとっちがえ、
そのまま同じファイルのつもりで
同名ファイルをコミットしそうだけど。

575:デフォルトの名無しさん
08/04/23 16:31:18
>>573
>同じフォルダに大文字小文字が違うだけの同名ファイルをおくのはlinuxだと普通なのか？
クライアント側がWindowsだからこそ、大文字小文字を変に気にするやつが
コミットする時に小文字を大文字に変えたりしてコミットしようとするんだよ
実際はファイル名を変えた時点で管理外になるんだけど、
考えなしに追加、コミットしてくるやつが以前いたもんで

まぁうちの人間がおかしいって言われればそれまでなんだけど
SVNで使ってるリポジトリは大文字小文字を別物として
捉えるってのを最初にちゃんと言っておくべきだって話

576:デフォルトの名無しさん
08/04/23 16:36:35
MakefileとMAKEFILEとmakefileがコミットされて殺意が湧いた事ある

577:デフォルトの名無しさん
08/04/23 16:45:39
TortoiseSVNで名前の変更をした場合

大文字、小文字のみのリネームは出来ません

って警告してくるんでそこで気付いてくれれば良いんだけどね

578:デフォルトの名無しさん
08/04/23 18:19:02
ソースファイルじゃなくてデータファイルなんかのときに困ね
テストを実行したら「ファイルが見つかりません」って大文字小文字違いかよ・・・みたいな

579:デフォルトの名無しさん
08/04/24 00:10:21
むかしWindows使いからやってきたjavaのソースファイル名がクラス名と大文
字小文字が揃っておらず、えらい難儀した記憶がある‥‥‥。

580:デフォルトの名無しさん
08/04/24 06:11:48
>>577
このメッセージは逆に紛らわしいと思う

リポジトリ側でも大文字小文字は区別されないのかと考えてしまうよ

581:デフォルトの名無しさん
08/04/24 09:29:39
>>580
ヘルプ読んでほしいなぁ……

582:デフォルトの名無しさん
08/04/24 12:26:47
TortoiseSVNはWindows専用のクライアントなんだから
そうするのが当たり前だと思うが
実際にそれをコミットしたらTortoiseSVNでチェックアウトすると
その部分でAbortが発生する

ヘルプはちゃんと読んでないのでどう書いてあるのか知らんけど

583:デフォルトの名無しさん
08/04/24 13:02:46
WindowsじゃなくてもFATをマウントしていたらどうなるんだ

584:デフォルトの名無しさん
08/04/24 13:22:36
>>580
＞このメッセージは逆に紛らわしいと思う
いやべつに。
直接的な理由は言ってるし、それ以上厳密にしたってしょうがない。

585:デフォルトの名無しさん
08/04/27 03:29:41
trunk の一部を切り出して、管理の外で作業したいものがあるので、
tar でまとめています。

tar でアーカイブする時に各ディレクトリごとの .svn が含まれてしまうのを
避けたいのですが、何かいい方法はありませんでしょうか。

作業場所で解凍した後に、find hoge -type d -name '.svn' -exec rm -rf '{}' ';'
という解決策以外を探しています。

586:デフォルトの名無しさん
08/04/27 03:50:22
tarでアーカイブするときに.svnを除外する。

587:デフォルトの名無しさん
08/04/27 03:52:26
find の使い方分かってるなら、
tar に渡すファイルを find 使って指定すればいい。

588:デフォルトの名無しさん
08/04/27 03:55:57
サイズが小さいなら毎回exportでもいいんでは

589:デフォルトの名無しさん
08/04/27 04:03:19
>>586
最近のtarならtar cf --exclude-vcs foo.tar . だけだしな。

590:デフォルトの名無しさん
08/04/27 05:30:51
ありがとうございます。tar のオプション知りました。
あいにく 1.14 で古かったのですが

tar cz --exclude=.svn -f hoge.tar.gz .

find でファイル指定するのは
tar czf hoge.tar.gz `find . -type f ! -name '*/.svn/*'`
としてみて惨敗だったので。。

591:デフォルトの名無しさん
08/04/27 05:33:50
find . | grep -v '/\.svn/'

592:デフォルトの名無しさん
08/04/27 05:48:01
その手がありましたね。。find よく知らなかった頃は
いつもパイプで処理してたのに。。頭かたくなった。

ところで、今回の発端は、synbolic link で管理している
ファイルやディレクトリを windows　上では実体化して
作業したいというものです。
tar czhf hoge.tar.gz .

svn export で synbolic link を実体化してくれると
他の作業者に説明しやすくて嬉しいのですけど。

593:デフォルトの名無しさん
08/04/27 10:21:33
いずれにせよシェルスクリプト化するんなら同じじゃね？

594:デフォルトの名無しさん
08/04/27 18:22:08
あー、たしかに TortoiseSVN で複数行入力可能だけど、
ログみるときリストにはずらりと一行目が表示されるもんな・・・

一行目はサマリーか、参考になる

>>567
・Windows serverをやめる
・coLinuxか、andLinuxを使う

595:デフォルトの名無しさん
08/04/28 04:11:27
svn st で、特定の状態のもののファイル名だけ単純に一行に
ひとつずつ出してくれるようにできれば便利なんだけどなぁ。
いちいち出力を sed とか awk とかで篩い分けて xargs に渡して
って面倒。まぁ一度スクリプトを書いてしまえばいいんだけど。

596:デフォルトの名無しさん
08/04/28 08:15:37
そのうちxml queryができるようになるよ

597:デフォルトの名無しさん
08/04/30 17:09:41
Subversion 1.5.0 Release Candidate 4 Released
URLﾘﾝｸ(svn.haxx.se)

598:デフォルトの名無しさん
08/05/06 07:09:33
subversionのレポジトリってOS間で移動しても大丈夫ですか？
つまりいままでlinuxにあったレポジトリをwindowsのNTFSに
そのままコピーして使って大丈夫でしょうか？

マニュアルによると
Berkeley DBと違ってFSFSなら
プラットフォームに独立した保存形式ということなんですが。

599:デフォルトの名無しさん
08/05/06 08:04:31
余り薦められたもんじゃないけど、USBメモリにリポジトリを入れておいて
Linux端末に繋いでもWindows端末に繋いでも使えるから大丈夫でしょ。

600:デフォルトの名無しさん
08/05/06 12:32:31
どっかのサーバーに置いとけばいいんじゃないの？

601:デフォルトの名無しさん
08/05/06 13:02:02
サーバーに置けるんだったら、そのサーバーで Subversion 動かした方がよくね？

まあ、いろいろ制約があるのかも知れないけど。

602:デフォルトの名無しさん
08/05/06 13:16:21
>>598
Subversionのバージョンが大きく下がるとダメなことがあるかも。
壊れたりはしないけど「フォーマット新しすぎ」とか言われるはず。

svnadmin dump → svnadmin load が安全なのでお勧め。

603:デフォルトの名無しさん
08/05/06 17:10:43
>>602
それはワーキングコピーのほうじゃないかい？

604:デフォルトの名無しさん
08/05/06 19:34:26
>603

レポジトリもどっかで非互換になった気がする...もう記憶の彼方だけど...

605:599
08/05/06 19:47:17
あー、>602は経験ありますよ。確か、cygwinのクライアントが古くて読めなかった。
勿論、更新して回避。今はcygwinのsvnじゃなくて本家サイトから落としたのを使っているけど。

606:デフォルトの名無しさん
08/05/06 20:07:40
>>603
レポジトリにもバージョンがある (format に書いてある) ので、
バージョン間で非互換の部分があるかもしれない。
(俺は見たことないけど。)

ので、安全を期すなら >>602 の言う通り dump - load が確実。

607:デフォルトの名無しさん
08/05/06 20:35:07
.svn/entries がxmlじゃないフォーマットになったけど、
その仕様ってどっかにある？
本家のDocumentとかみたけどAPI使え的なのしか発見できなかった。

608:デフォルトの名無しさん
08/05/06 22:28:27
>>603
つ svnadmin dump --help

609:598
08/05/07 00:33:38
svnadmin の dump load 知りませんでした。
これ使ってみます。ありがとうございました。

610:デフォルトの名無しさん
08/05/07 02:02:03
>>600
LinuxのサーバからWindowsのサーバに移動するというケースも忘れてはならない。

611:デフォルトの名無しさん
08/05/07 02:19:36
>>607
全部読んでないけど、これかな？
URLﾘﾝｸ(svn.collab.net)

612:デフォルトの名無しさん
08/05/07 14:52:26
username として可能な文字列ってどんなだったっけ？
たとえば subversion 的には OpenID の Identifier みたいな
URI でも username として受け付けてくれるんだろうか。

613:デフォルトの名無しさん
08/05/07 20:21:43
>>610
今時は OS の違いなんてあまり重要じゃないでしょ。

Samba なり Service for Unix あたりでなんとでもなるだろうし。

614:デフォルトの名無しさん
08/05/07 22:03:39
わかってないな。
見た目上似せてるがゆえに
かえってFSとかの仕様の細かい差異がむしろ問題になりうる。

615:デフォルトの名無しさん
08/05/07 22:21:06
リポジトリのファイルってリビジョン番号とかだし、そんなに影響ある？
そこまで違いに敏感だと困るんじゃないか？

616:デフォルトの名無しさん
08/05/07 22:40:27
昔の知識引きずってる爺だろ、放置推奨。

617:デフォルトの名無しさん
08/05/07 23:13:10
具体的に何がおきるの？

618:デフォルトの名無しさん
08/05/08 01:35:23
わかんないんです（＞＜）

619:デフォルトの名無しさん
08/05/08 05:01:52
デフォルトのFSFSならリポジトリにOSの違いは無い、のではなかったっけ？
BDB <-> FSFS とか、BDBのバージョンが異なる場合とかなら、
svnadmin dump/load が必要。
でも、今時（Subversion 1.2以後）はデフォルトがFSFSなので、
気にする必要がないよね。

あと、Subversion 1.3 -> 1.4のようにリポジトリの形式が変わったときも、
Subversionはどちらの形式でも扱えたのでdump/loadは不要だったけど、
dump/loadして新しい形式にすればリポジトリが小さくなる、という
御利益があった。

URLﾘﾝｸ(www.google.co.jp)

URLﾘﾝｸ(subversion.tigris.org)
URLﾘﾝｸ(subversion.tigris.org)

620:デフォルトの名無しさん
08/05/08 18:53:07
そんなことより、なんでもかんでも（バイナリなデータも）
放り込んで肥大化して言っている漏れのプロジェクト、
サイズ的にはどの程度になったら破綻するのか気になる。

まぁワーキングコピーで svn st が1分以上かかるようになったらやばいか。
っていってもワーキングコピーはリポジトリの一部だからなぁ。
リポジトリ自体はどの程度の規模になったら破綻するんだろう。

もしかして100GBとかのリポジトリでも成立するのか？
そしてリビジョン番号が1000万とか。

621:デフォルトの名無しさん
08/05/08 19:59:34
>>620
Revが65万くらいのはよく見かける。

622:デフォルトの名無しさん
08/05/09 03:07:21
　　　　　　　ヽ|/
　　　　／￣￣￣｀ヽ、
　　　 /　　　　　　　　ヽ
　　　/　＼,, ,,／　　　|
　　　|　（●）（●）|||　 |
　　　| 　/￣⌒￣ヽ　U.| 　　・・・・・･･･ｺﾞｸﾘ。
　　　|　 | .ｌ~￣~ヽ |　　 |
　　　|U ヽ￣~￣ﾉ　　 |
　　　|　　￣￣￣　　　 |

一体どんな使い方をしたらそんなに数を重ねるんだろうか。

623:デフォルトの名無しさん
08/05/09 03:19:06
URLﾘﾝｸ(websvn.kde.org)
ここはRev.が80万超えてる。

624:デフォルトの名無しさん
08/05/09 21:56:30
svnmanager って管理用データベースと実際のリボジトリの間の整合性が取れなくなると悲惨。
Webベースで svnadmin 相当の操作やアクセス制御の操作ができるいいツールないかな？

625:デフォルトの名無しさん
08/05/10 16:16:02
またこの話か・・・・

626:デフォルトの名無しさん
08/05/10 16:28:08
すまん。
みんなどうやっているのか知りたかったんだ

627:デフォルトの名無しさん
08/05/11 19:10:16
キーワード置換と等価な作業をバイナリファイルに施したいです。
つまり、リビジョン番号や日付を任意のフォーマットでファイルに埋め込む作業を
コミット時に自動で行いたいです。これを実現する方法はあるでしょうか？

フックスクリプトでできるかなと思ったのですが、方法が解らず悩んでいる状況です。
(svnlook cat でファイル内容の取得はできるが、内容の編集方法がわからない)

ご教示のほど、どうぞ宜しくお願い致します。

628:デフォルトの名無しさん
08/05/11 20:01:22
>>627
svn:keyword でバイナリ用の置換マーク使うんじゃ何か不満か？

629:627
08/05/11 22:01:10
>>628
バイナリの中にデフォルトの置換文字列を埋め込む、ってことですよね？
99.99%以上大丈夫だけど、たまっっったま置換文字列と同じパターンのデータが
紛れた時にどう対処するか？っていう事を考えていて、上記質問と相成りました。

pre-commitでパターンの重複をチェックして水際でデータの破壊を防ぐ、ってのが
ひとつの方法ですが、置換を自前スクリプトで制御する方が綺麗な方法かなと思いまして。。。

630:デフォルトの名無しさん
08/05/11 22:07:38
>>629
なるほどね。でもコミットされるリビジョンの編集はフックではできないから、
pre-commit ではじくってのが一番現実的な感じ。自前のスクリプトでやるとしたら、
実行タイミングでまた悩むと思う。

631:デフォルトの名無しさん
08/05/11 23:10:08
>>627
現状では無理。

テキストのキーワード置換はクライアント側で行われているから、
クライアントを改造するのがまっとうな方法。

632:デフォルトの名無しさん
08/05/11 23:25:09
importした時のファイルのタイムスタンプを保存する方法ないですか？
後からcommitするファイルのタイムスタンプは
commitした時刻で構わないんですが。

633:デフォルトの名無しさん
08/05/11 23:43:55
>>632
1.6で実装されるかもしれないとか。issue1256

とりあえず適当な属性作って保存しておくとか。

634:627
08/05/12 20:39:01
>>630
>>631
ご助言ありがとうございました。
結構いけるかなと思いましたが意外と難しいですな。。。

635:デフォルトの名無しさん
08/05/17 03:12:12
TortoiseSVNの質問です。

TortoiseSVNで認証が必要なサーバーにコミットするのに、
パスワードの入力が必要なくコミットできたのですが、
これは何故でしょうか？

以前、そのサーバーにはコマンドライン版の svn にて認証を通し、コミットしたことがあります。
svnでは、
C:\Documents and Settings\（ユーザー名）\Application Data\Subversion\auth\svn.simple
などにユーザー名、パスワードなどを保存しているようなのですが、
TortoiseSVNでもこの設定を読んでいるのでしょうか？

636:デフォルトの名無しさん
08/05/17 10:59:28
TortoiseSVN のヘルプ開いて目次の

　TortoiseSVN - 日常操作ガイド - さぁはじめましょう - 認証

を参照。

ちなみに共有するのが嫌なら、

　TortoiseSVN - 日常操作ガイド - TortoiseSVN の設定 - レジストリ設定

を見れば、変え方が分かる。

637:デフォルトの名無しさん
08/05/17 15:55:50
>>636
サンクス！
ヘルプにあったんですね。
というか日本語ヘルプの存在をはじめてしったｗ

Subversionの設定をそのまま使うんですね。
簡単な認証なら便利ですね。

レジストリの設定は、レジストリに該当箇所（ConfigDir）が見つけられなかったけどたぶんSubversionの場所をさしているんでしょう。

638:デフォルトの名無しさん
08/05/18 07:33:15
あれ？いまの TortoiseSVN のバイナリパッケージって、svn.exe
自体は含まれてないんだったっけ？
c:\Program Files\TortoiseSVN\bin
以下に入っているものとばかり思っていた。

639:デフォルトの名無しさん
08/05/18 10:07:57
なんかコメントがカオスになってきてるんだけど
いい感じのコメント規則ってないですかね？

640:デフォルトの名無しさん
08/05/18 15:36:04
>>638
不要じゃろう

641:デフォルトの名無しさん
08/05/19 04:17:49
svnsync って双方向じゃないのが不便だね．
リードオンリーのミラーを作るって，バックアップ目的
以外に使い道ある？

642:デフォルトの名無しさん
08/05/19 10:06:13
双方向のニーズって何？
USBに入れて持ち歩いたり、なんちゃって分散リポジトリもどきでもやるのか。

643:デフォルトの名無しさん
08/05/21 14:19:52
リポジトリを作るときにtrunk,tags,branchesを作らずに全部直下に
入れる構造にしていて、後で直したいと思ったときはどうすればいいですか？

3個をmkdirして現在直下にあるファイルをmvすると、mvのたび
（つまり直下のファイルと同数だけ）リビジョンが増えてしまうのですが、
もっといい方法はありますか？

644:デフォルトの名無しさん
08/05/21 15:51:05
ファイルを1つ動かす度にコミットしなければ良い。

645:デフォルトの名無しさん
08/05/21 16:00:05
そういえば
% svn {mv,cp} hoge.txt hage.doc hige.c dir/

って複数のmv/cpは書けないって知ったときは目が点になったな。
最新版では書けるのかな。今のところforで書いてるけど、タルい。

646:デフォルトの名無しさん
08/05/21 16:09:20
>>643
簡単な解決策：　リビジョン番号が増えるのを気にしない

647:デフォルトの名無しさん
08/05/21 17:24:58
バグに対する簡単な解決策：バグがあるのを気にしない

648:デフォルトの名無しさん
08/05/21 21:51:39
>>645
改造して、patch を公開してくれるとプチヒーローになれるかも。

>>646
リビジョン番号はあまり気にしないけど、似たようなログが３個も
あるのはすごくダサいと思う。

649:デフォルトの名無しさん
08/05/21 22:57:10
>644 で解決じゃないの？

650:つーか、単なる雑談だわ。
08/05/22 00:38:43
あ～、リビジョン番号の方は解決済みだよ。

より簡単な方法を模索してるだけ (w

651:デフォルトの名無しさん
08/05/22 01:29:53
>>643
リポジトリのルートからのコピーで trunk を新規作成すればいい。
URL 指定のリポジトリ内コピーで一発。

652:デフォルトの名無しさん
08/05/22 07:43:28
自分ならdumpして加工してloadするが

653:デフォルトの名無しさん
08/05/22 12:40:53
Subversion はワーキングコピーが内容の二倍になっちゃうけど、
他のバージョン管理システムでも同じようなものなの？
diff をとろうとする以上そうなってしまうような気がする。

654:デフォルトの名無しさん
08/05/22 13:21:08
今の subversion には text-base 以下を再び
リポジトリから持ってきて修復する手段がないよね

655:デフォルトの名無しさん
08/05/22 14:10:39
>>643
svn rm *
svn cp `svn info | ruby -e'$<.grep(/^URL:\s*(.*)/){print $1}'` trunk
svn mkdir tags branches
svn ci
>>645
確か 1.5 からできる。

656:デフォルトの名無しさん
08/05/22 22:00:18
>>651
なんで、リポジトリ内コピーなんてするんだ？

>>643 はワーク内で移動/コピーして一気にコミットしたいんだと思うが。

>>653
管理ファイルもあるから、２倍＋αだな。

まあ、BASE ファイルを圧縮するとか複数のファイルをまとめて管理する
とかのちまちました削減策は可能だけど、HDD の GB 単価が 20円を切っ
てる状況では多少のディスク容量と引き換えにプログラムを難しくする
必然性はないだろうな。

次ページ