Subversion r11 - 暇つぶし2ch

Subversion r11 ..

49:デフォルトの名無しさん
09/01/30 20:38:58
>>48
削除をコミットしてから前のリビジョンをエクスポートすればいいんじゃないか

50:デフォルトの名無しさん
09/01/30 21:43:06
>>48
--keep-localオプションでどう？

51:デフォルトの名無しさん
09/01/31 01:43:23
svn delete URL

52:デフォルトの名無しさん
09/02/02 15:48:23
Tortoiseでもシフトキー押しながらコンテキストメニュー出すと>>50と同等な項目が出るんだね。

53:デフォルトの名無しさん
09/02/03 02:38:18
返事が遅れてすいません
みなさんありがとうございます

>>49
言ってなかったので本当に申し訳ないんですが、残したいファイルは変更してることがあるんです
ただ、変更がなければそっちのほうがいいような気がするので参考にさせていただきます

>>50
まさにこれだ
っと思ったけどsvnのバージョンが古くて私のとこにはありませんでした

まぁ、わざわざオプションが追加されたということは
コマンド一発でやる方法はないんだろうということででしょうね

>>51
URL で指定して、レポジトリから削除して、ローカルのを管理対象から外せばいけますね

54:デフォルトの名無しさん
09/02/04 20:54:44
Subversionの管理下にあるファイルを管理から外したいんですが、どうやればいいんでしょう？
クライアントはEclipse使ってます。

55:デフォルトの名無しさん
09/02/05 03:03:22
>>54 >48

56:デフォルトの名無しさん
09/02/05 23:14:51
subversionいれてdigest認証にしたんですが
Digest: user `xxx' in realm `Subversion Repository' not found: /svn/test/
というエラーが出ます
レポジトリは作ってるんですがパスワードを入力してもアクセスできません
どうしてでしょうか？

57:デフォルトの名無しさん
09/02/05 23:18:01
>>56
エラーメッセージによると xxx というユーザーが Subversion Repository というレルムに存在しないらしいが
認証ファイルはちゃんと作れてるか？

58:デフォルトの名無しさん
09/02/06 00:21:01
>>56
ありがとうございますいろいろ試したんですが結局うまくいかなかったので
SSL+Basic認証にしました

59:デフォルトの名無しさん
09/02/06 06:16:44
firefoxからだとレポジトリが見えるんですが
svnコマンドを使ってレポジトリを調べると
No repository foundになります
どうしてですか？

60:デフォルトの名無しさん
09/02/06 10:01:13
>>56
俺の環境ではDigest認証でちゃんと使えている

61:デフォルトの名無しさん
09/02/06 15:13:41
俺も Digest うまくいってるな。
まあ SSL できるならそっちの方がいい気がするが。

62:デフォルトの名無しさん
09/02/07 13:33:20
subversion + apache で使ってるんですが、CGIとかJavaScriptでIE等のウェブブラウザからファイルの更新をできるようにするフリーのモジュールはありますか？

63:デフォルトの名無しさん
09/02/08 14:45:22
質問なのにあげてなかった。　すまん。

64:デフォルトの名無しさん
09/02/09 09:16:38
>>62
まるで存在価値がないな。

65:デフォルトの名無しさん
09/02/09 09:36:59
webdavで使うとか。
本来の使い方じゃ無いけど。

66:デフォルトの名無しさん
09/02/09 21:13:08
>>65
やってみたらコミットどころか、ファイルの新規追加すらできなかったわ。。。

67:デフォルトの名無しさん
09/02/09 21:27:27
>>65
Autoversioning追加で解決しました。　ありがとうございました。　私が早漏でした。

68:デフォルトの名無しさん
09/02/12 22:01:00
TortoiseMergeで複数行を選択して、このテキストボックスを利用を押してから
保存するとその行の改行が無くなるんだけど、同様の症状の方います？
一行ずつだと大丈夫なんですよね。
verupしたせいかな・・・

69:デフォルトの名無しさん
09/02/13 01:40:41
>>68
URLﾘﾝｸ(tortoisesvn.tigris.org)

70:デフォルトの名無しさん
09/02/13 12:07:11
>>69
ありがとうございます。
やはりバグでしたか・・・

71:デフォルトの名無しさん
09/02/14 08:18:24
TortoiseSVN 1.5.8 age

>>68-70
> Version 1.5.8
> - BUG: TortoiseMerge could loose line endings when saving edits. (Stefan)

72:デフォルトの名無しさん
09/02/15 01:02:46
ファイルがコミットされた時にpost commitでフックして、コミットされたファイルから
情報を取り出してデータベースに格納したいのですが、いい方法はありますか？
要はpost commitの中でコミットされたファイルの中身を見たいという事です。

73:デフォルトの名無しさん
09/02/15 01:15:50
>>72 svnlook cat

74:72
09/02/15 01:24:49
>>73
おー、そのものずばりのコマンドがあるんですね。
ありがとうございました。

75:デフォルトの名無しさん
09/02/16 16:41:48
最近バージョン管理をVSSからTortoiseSVNに変えたときに
Ver.1.0用のリポジトリとVer.2.0用のリポジトリをそれぞれ作って、
最初は同じコードをインポートしたんだけど、

それぞれ別の機能が実装されていってったから
今は多くの部分が共通でありながら一部違うみたいになってます。

この状況で、Ver.2.0のリポジトリがいらなくなったから1.8のほうに
統合したいんだけど、リポジトリ違うときのマージの方法がわからん

うまい方法ってない？

76:デフォルトの名無しさん
09/02/16 16:49:13
>>75
マージしたいバージョンをチェックアウトしてインポートしてマージ

77:デフォルトの名無しさん
09/02/16 16:54:49
>>76
さっきやってみた。
マージメニューの"ブランチを再統合する"ってやつは元が違うからできんかったな。
この場合は"異なる2つのツリーをマージ"ってやつでいいの？

78:デフォルトの名無しさん
09/02/16 17:00:36
どこに躓いてるんだｗ
別レポジトリのファイルでもチェックアウトしたものを
新しいレポジトリにインポートすればsvnの構造上ブランチと違いはない

79:75
09/02/16 17:16:18
マージすらままならんsvn初心者なんだよ、すまん。ありがとう
出直してくる

80:デフォルトの名無しさん
09/02/16 17:32:02
１）もともとのソースコードの公開は開発元からに限られている
２）差分の公開は自由にしてよい

こういうときって，リポジトリ自体をライセンスに合った形で
公開したり，みんなで機能追加をつっつく方法って無いですか？

古いコードで，もともとの作者にもはや連絡が取れない場合とか，
ライブラリ製品だとそういうライセンスのやりかたを
取ってるものなどがあって，どうしたもんかなぁ，と．

完全にオープンソースのものだと楽なんですが・・
いいアイディアはないでしょうか？

リビジョン 1 はリポジトリには入ってないけど
みんな手元に同じ tar ball 持ってるよね？
って状態でその後をオープンにいじりたいというのは無謀？

81:デフォルトの名無しさん
09/02/16 22:13:03
>>75
Ver1.8と最初のコードの差分を指定してVer2.0にマージする。これでリポジトリ間のマージはできるよ。
ただし、svn:mergeinfoはリポジトリ名が入らないんで矛盾が生じるので該当部分は消す。

82:デフォルトの名無しさん
09/02/17 15:53:21
編集したはいいけどやっぱブランチにしとけばよかったぜ！
みたいなときってどうすんの？

83:デフォルトの名無しさん
09/02/17 16:01:47
あきらめる

84:デフォルトの名無しさん
09/02/17 16:09:58
>>82
私のリポジトリは、しばしばtagからbranchしているw

85:デフォルトの名無しさん
09/02/17 16:54:37
え、それ普通でしょ？

86:デフォルトの名無しさん
09/02/18 12:19:25
>>82
そのままブランチすれば問題ないよ。

87:デフォルトの名無しさん
09/02/18 13:03:34
trunkには、直近の変更は入れたくないけどどうしようって質問だと思ったが。

88:デフォルトの名無しさん
09/02/18 13:55:19
それtrunkじゃないじゃん

89:デフォルトの名無しさん
09/02/18 14:35:59
何言ってんの

90:デフォルトの名無しさん
09/02/18 17:51:45
入れたくなければブランチすればいい話

91:82
09/02/18 19:31:20
>>86
そのままブランチしても作業コピーの変更はちゃんとブランチに入るってことでおｋ？

俺が知ってるのはあるリビジョンから新しく作って（と同時に切り替えて）
作業していくって方法だけだから、それだと編集中のやつ無駄になるやん、と思ってな

92:86
09/02/18 21:39:21
いや、作業コピーはそのままで分岐される。
TortoiseSVNの場合はリポジトリ内で最新リビジョン＋切り替えるで分岐をすると作業コピーは変更されずに分岐ができる。
その後コミットすれば変更内容をリポジトリに格納できる。
よくやるのは、>>84のとおりtagsの作業コピーを編集した場合、そのままbranches上に分岐させる。変更が終わったらそのまま分岐をtrunkにマージできる。

93:デフォルトの名無しさん
09/02/19 04:36:14
ドメインとかIPかわっちゃった場合はどうやって変更かえればええんでしょうか？

94:デフォルトの名無しさん
09/02/19 05:11:44
>>93
先ず日本語で質問する。

95:デフォルトの名無しさん
09/02/19 05:53:01
relocate じゃね？

96:82
09/02/19 09:14:10
>>92
詳しい説明マジｔｈｘ！

97:デフォルトの名無しさん
09/02/19 10:51:40
再配置

98:デフォルトの名無しさん
09/02/19 23:09:32
svn switch で、どこにでも変更できたと思うけど。

99:デフォルトの名無しさん
09/02/20 13:00:16
>>98
switchとrelocateは別物。

100:デフォルトの名無しさん
09/02/20 18:14:15
>>98
switcgiはリポジトリ内でしか変えられない
relocateはリポジトリのurlしか変えられない。

101:デフォルトの名無しさん
09/02/20 18:25:21
Windows版のコマンドラインクライアントってどこからダウンロードすればいいんでしょうか？
なんか登録サイトが出てきて、ダウンロードできない・・・。
以前は普通にダウンロードできたんだけども。

102:デフォルトの名無しさん
09/02/20 18:31:58
ああ、Windows binaries のリンク先の tigirs.org の apache 2.0 のリンク先からいけました。
紛らわしいなあ・・・

103:デフォルトの名無しさん
09/02/20 19:27:22
>>101
sourceをおいてあるツリーのところにバイナリがおいてあった。
あと、binaryのリンク先のcollabnetでダウンロードする。collabonet subversionをダウンロードすると
collabnet desktopをダウンロードする様に出てくるけどこれってどんな機能があるのか良くわからないな？誰か知ってる？

104:デフォルトの名無しさん
09/02/20 20:13:06
スレチ

105:デフォルトの名無しさん
09/02/21 10:40:00
補足：>>104がスレチって意味です。

106:デフォルトの名無しさん
09/02/21 10:47:38
>>103
ググレカス

107:デフォルトの名無しさん
09/02/22 02:00:19
OpenOfficeのファイルをsubversionで管理している人はいますか？
ODF(OpenDocument Format)ファイルが大きくなると、小さな変更に対しても差分が上手にとれずに、
レポジトリが肥大化することはありませんか？
ODFファイルをsubversionでどう扱うかはWeb上にいくつか情報がみつかるんだけど、
どうすればよいのかよくわからない。デフォルトでは、subversionがバイナリファイル扱いをして、
差分はxdeltaでとられるみたい。xdeltaは、大きなODFファイルの小さな変更に対して、十分に小さい
差分を生成できるの？
また、ooosvnも試したけど、Windowsで使えないのが難点。ファイル名やパスの書き方の問題だけな
気がするが。
ここら辺の問題意識は何年も前からあるみたいだけど、あまり解決していないのは、binary形式での
管理で十分ということなのだろうか。

108:デフォルトの名無しさん
09/02/22 04:32:57
>>107 試せばいいじゃん。

109:デフォルトの名無しさん
09/02/22 11:31:13
>>107 試したよ。手順は以下の通り。
内容はほぼテキストのおよそ36kbのファイルをOpenOffice Writerで作成、svnにimportする。
レポジトリ以下のファイルサイズを記録しておく。OpenOffice Writerでドキュメントをわずかに変更。
svnにcommitする。レポジトリ以下のファイルサイズを見て、commit前のと比較。/db/revs/0が36kb程度
増加していることを確認。よって、上手に差分がとれていないと結論。

110:デフォルトの名無しさん
09/02/22 11:50:01
zipかよ。圧縮のせいで元が大きく変わってるから差分手法のせいじゃない。
zipをバラしてから差分を取るといった具合に専用に最適化させないと無理。

111:デフォルトの名無しさん
09/02/22 11:51:37
？？？
Subversionって、テキストファイルとバイナリファイルで差分の取り方って
違うの？

URLﾘﾝｸ(dolphin.c.u-tokyo.ac.jp)
の「バイナリファイルの効率的な取扱い」とかを見て、一緒の扱いを
しているもんだと思っていたんですが。

112:111
09/02/22 11:53:52
ああ、そうか、>>110を見て、ODFの中身がZIPだということを認識した
なるほど・・・そりゃムリだｗ

113:デフォルトの名無しさん
09/02/22 12:40:06
ODFにしてもマイクロソフトの.docxみたいなのにしても、
なぜ非圧縮での保存というオプションが無いのだ。

114:デフォルトの名無しさん
09/02/22 14:36:37
gitやmercurialはdiffをODFファイルのdiffをとるプログラムが設定できるらしいが、
これもレポジトリレベルでは、単なるバイナリdiffしかとっていないのでは?
そうすると 113>> のように、アプリケーション側でsubversionに対応するしかないのかな。
確かにUML Editorを使っていたのだけど、subversionと連携するように、非圧縮のXMLにして
保存していたような気がする。
しかし、プロジェクトでODFファイルを共有して皆で編集したいというニーズにはどうすれば
いいのかな？plain textかHTMLで文書を書けという方針にするかな。

115:デフォルトの名無しさん
09/02/22 14:48:04
どんな運用かわからないけど、いまどきのストレージ事情でごり押しできない？

116:デフォルトの名無しさん
09/02/22 15:01:19
LaTeXで書け

117:デフォルトの名無しさん
09/02/22 19:52:32
>>115 おっしゃる通り、ゴリ押しすることにしようっと。しかし、ドキュメントが大きくなると
破綻するのは、目に見えているな。そういうときは、過去のバージョンをパージしたりするのかな。
>>116 自分はLaTeXで書いているんだけど、プロジェクトのメンバーにLaTeXを強要するのは酷だなと
思って調べだしたのが、今回のきっかけ。
OpenOfficeの側にバージョン管理システムフレンドリーにしてとリクエスト出すべきかな。
しかし、バージョン管理システム側の設定でバイナリ差分のとり方を設定できるようにするのは、
一見いいアイディアのように見えて、リポジトリの移行時などに問題が発生するので難しい問題ですね。

118:デフォルトの名無しさん
09/02/22 21:14:59
よーしらんが、コミットフックでzip展開させるわけにはいかないんかい？

119:デフォルトの名無しさん
09/02/24 16:55:36
使い始めたばかりで、間違った使い方してるのかもしれませんが教えて下さい。
TortoiseSVN + subversionです。
チェックアウトのリポジトリURLを「file://aaa/b/ccc/ddd」として、編集、コミットをした後
ログで作者の欄を見るとちゃんと入ってますが、
チェックアウトのリポジトリURLを「svn://xxx/yyy」として、編集、コミットをした後
ログで「作者」の欄を見ると空欄になってます。
何か設定などあるのでしょうか？

120:デフォルトの名無しさん
09/02/24 17:29:48
login

121:デフォルトの名無しさん
09/02/24 19:17:03
file://aaa/b/ccc/ddd でチェックアウトしてコミットしたものは、Windowsならそのユーザ名が入る
svn:// でやってるんなら最初にログインしてないと空白になる

svnserveで認証するようにすれば良い

122:119
09/02/24 19:47:42
>>121
ありがとうございます。
無事できました。

123:デフォルトの名無しさん
09/02/25 21:45:28
subversion + TortoiseSVNの構成で svn:// にて使用しております。
現在は confフォルダ内の設定ファイルに記述したユーザ及びパスワードにて
認証しておりますが、Windowsのユーザで認証することは可能でしょうか？

124:デフォルトの名無しさん
09/02/25 22:34:38
>>123
URLﾘﾝｸ(tortoisesvn.net)

Svnserveベースじゃ無理っぽい。Apacheベースにする必要がありそう。
もちろん、アクセスもsvn://ではなくなる。

125:デフォルトの名無しさん
09/02/26 21:47:25
>>124
ありがとうございます。
やっぱりapacheが必要なんですね。
なんとかなるといいんですが．．．

126:デフォルトの名無しさん
09/02/26 23:33:32
１つのリポジトリを、複数台のサーバからアクセスする構成を組みたいのですが
そういう構成は安全でしょうか？

具体的にはWindows共有サーバ上にリポジトリをFSFSで作成し、多数のサーバ
（WindowsやLinux等）を使って多数のユーザで使用することを考えています。

127:デフォルトの名無しさん
09/02/27 02:10:57
ちょっと違うかもだけど、参考になる？

複数リポジトリアクセス方法のサポート
URLﾘﾝｸ(subversion.bluegate.org)

128:デフォルトの名無しさん
09/02/27 17:48:26
認証システム的にはCIFS(samba)+fileスキームで可能だけど、fileスキームでの
アクセスが適切なのかはあんたの利用状況に依存。

129:126
09/02/28 01:12:33
>>127-128
ありがとうございます。なんとか出来そうな感じですね。
とりあえずやってみることにします。

130:デフォルトの名無しさん
09/02/28 09:09:28
いま、仕事場で svn+sshでsvnユーザーさんでアクセスしてコミットしてもらっとるんですが、
これって誰がコミットしたかわからない、ですよね？

全部svnさんになる？TortoiseSVNですが、自動でWindowsログインユーザーとかにはならないですよね？

ユーザーを認識するにはどうしたらいいんでしょ？

svnのサーバーで利用者ごとにユーザー作って、
リポジトリのディレクトリにアクセスできる権限設定して、
そのユーザーにssh公開鍵置いてアクセスしたら、鯖で作ったユーザーで記録残る？
この辺のドキュメントありませんでしょうか？

131:デフォルトの名無しさん
09/02/28 09:14:04
やっちまった～
svnsync でミラーしてリードオンリーで公開したつもりが、
そっちからチェックアウトしてコミットした奴らと
もともとのリポジトリにコミットした奴らが。
内輪のプロジェクトなのでおおごとではなかったけど、
こういうときはもうどうしようもないっすか？
ないっすよねぇ・・・・

132:デフォルトの名無しさん
09/02/28 09:16:06
>>131
分散系だと別段問題ないけど、中央集権だと大変だな、こういうときは

133:131
09/02/28 09:41:55
>>132
この場合、uuidが違うから気づいたのですが、
もしミラーをsvnsyncではなくrsyncやunisonを
使ってファイルシステムごとやっていたら、
uuidは同じわけで、気づくこともなくいつの間にか
違う歴史をたどり始めたuuidが同じ二つのリポジトリが・・

さらに被害甚大になっていたかと思うとガクブル。

134:デフォルトの名無しさん
09/02/28 12:56:34
>>130
その通り。利用者ごとにアカウントを作ってそのアカウントでアクセスすればよい。

135:デフォルトの名無しさん
09/02/28 13:04:40
>>130
マニュアル読めないの? メクラ?
URLﾘﾝｸ(subversion.bluegate.org)

136:デフォルトの名無しさん
09/02/28 16:27:32
>>135
そういうおまえは池沼だけどな

137:デフォルトの名無しさん
09/02/28 17:12:30
>>136
マニュアルに書いてあると、池沼に指摘されたお前は池沼以下だな。ｗｗ

138:デフォルトの名無しさん
09/02/28 20:52:03
まて、さすがに俺は答えてくれた方々に池沼なんていわない

139:デフォルトの名無しさん
09/03/01 02:15:37
ここは>>1が全て悪いということで、丸く治めようぜ

140:デフォルトの名無しさん
09/03/01 11:21:35
チェックアウトしたディレクトリが
あろうことか他の奴に削除されてしまったとき、
とりあえずそいつを一発殴った後で俺はどうすればいい？
昔のバージョンからブランチをひねり出して、
そこに switch すればいいのか？

まぁとりあえず今日のところは手元の変更点を diff 取って
そいつにメールで送りつけてお前のところでマージしやがれと
言っておいた。

141:デフォルトの名無しさん
09/03/01 11:27:26
「チェックアウトしたディレクトリ」ってなんだよ。
ワーキングコピーの事か? それなら他人に削除可能なワーキングコピーを作った自分を殴れ。
リポジトリのディレクトリの事なら、そいつのコミット分を戻せば行けそうな気がする。

142:デフォルトの名無しさん
09/03/01 11:40:11
>>141
用語の選択がまずかった。
俺がブランチ作った。ワーキングコピーをチェックアウトした。
奴がリポジトリ上でそのブランチ消しやがった。
svn commit できねぇ。

$ svn update
svn: Target path does not exist

$ svn commit -m "shine"
Sending abc.c
svn: Commit failed (details follow):
svn: File not found: transaction '5-9', path '/branches/mybranch/abc.c'

143:デフォルトの名無しさん
09/03/01 11:59:51
「ワーキングコピーをチェックアウトした」ってなんだよ。
ともかく、そいつコミット分を戻す（変更を逆方向にマージ）すれば行けると思う。

144:デフォルトの名無しさん
09/03/01 12:21:22
存在しないディレクトリとの差分って取れないだろ。
例え取れて差分戻してもディレクトリのUUIDは復活しないだろうから
> 昔のバージョンからブランチをひねり出して、
> そこに switch すればいいのか？
こうするしか無いように思える。

リポジトリのダンプとって削除を無いことにする。という逃げは有るだろうけど。

145:デフォルトの名無しさん
09/03/01 12:33:32
削除を逆マージすれば復活するし差分も取れるようになる。
リポジトリ内ならどこへでも切り替えできるし。
バージョン管理使ってるのに、たかが削除したくらいであわてる必要は無い。

146:デフォルトの名無しさん
09/03/01 12:53:45
>>145
まぁ確かにすべてのこっているわけだからあわてる必要は無いんだけど、
ゆとり世代は例外的事象の発生に弱いんだ。

>>144
UUIDはリポジトリに対して設定されるものなので、
「ディレクトリのUUID」というものは無い。
とはいえ、「こうするしか無いように思える」ってのは
俺もそう思うので、次からはそうする。

まぁオレ用ブランチを作った時点でサーバ側で
アクセス制御かけておけばよかったのかもしれないが、面倒だった。
というか、file: スキームでアクセスしている奴がいたらどうしようもないか。

とにかくだ、ゆとり世代がVCSを使うとこんな感じなのです。

147:デフォルトの名無しさん
09/03/01 13:26:08
>>146
まぁ自虐はそれぐらいにして次からはちゃんとしておけよ

148:デフォルトの名無しさん
09/03/01 14:06:12
Subversionを久々に使ってみたのですが、
エクスプローラで、ファイルのアイコンに付くマーク(緑丸とか赤丸の)が表示されなくなってしまったのですが
これは表示するようにできるんでしょうか？
※フォルダには付いてます。

149:デフォルトの名無しさん
09/03/01 14:11:26
F5

150:デフォルトの名無しさん
09/03/01 16:13:42
Ｆ５しても出なければアイコンオーバーレイの設定やフィルタを確認

151:デフォルトの名無しさん
09/03/01 16:30:58
蒸しリストに *.BAK を入れと *.bak が無視されなくなります。
蒸しリストに *.bak を入れると *.BAK が無視されなくなります。
トートイズsvn で windows 環境です。
たすけてくだしあ

152:デフォルトの名無しさん
09/03/01 16:34:24
>>151
両方入れたらどうなる？

153:デフォルトの名無しさん
09/03/01 16:50:09
>>151
×トートイズ
○トータス
△トートアス

先生はタートル(turtle)だったけど、トータス(taught us)。
-- from Alice in Wonderland.

154:デフォルトの名無しさん
09/03/01 17:18:58
ウルトラマンエースだったかな、キングトータスなんて怪獣がいたな。
もちろん巨大亀。

155:デフォルトの名無しさん
09/03/03 10:38:52
Tortoiseの発音はここで確認シル
URLﾘﾝｸ(www.thefreedictionary.com)

156:デフォルトの名無しさん
09/03/03 10:40:41
>>151
正規表現

例： *.[Bb][Aa][Kk]

157:デフォルトの名無しさん
09/03/03 10:59:50
正規表現というと誤解を招きそうな気がしないでもない

158:デフォルトの名無しさん
09/03/03 11:02:34
皆様すみません。

subversion-deps-1.5.5.tar.gzを
落としたかったのですが、公式が落ちているみたいで…。

どなたか、ミラーサイト等ご存知ですか？

159:デフォルトの名無しさん
09/03/03 12:02:45
158です。
すみません。復旧してました。

160:デフォルトの名無しさん
09/03/04 12:07:03
自分がチェックアウトして作業しているディレクトリの
パスの上の方でディレクトリ名が変更されたとき，
普通は switch というか switch --relocate しますよね？
これって自動的に追跡してくれないものでしょうか？

file:///repo/a/b/mycode

をチェックアウトして作業してたのに，管理者がそれを

file:///repo/x/y/mycode

に変更したときとか．これを知らずにワーキング
コピーを commit / update しようとすると
「そんなパスねぇよ」と怒られます．

リポジトリのログを見れば，自分がチェックアウトした
ディレクトリがその後どこに移動されたかわかりますが，
これが自動的に追跡されたらいいのになぁと思っています．

161:デフォルトの名無しさん
09/03/04 12:12:09
commit前にまずupdateしろって言われるだけだと思うが
updateすればそこでコンフリクトするんじゃねえのか

162:デフォルトの名無しさん
09/03/04 12:17:39
>>160
switchすればいいだけじゃないの？

163:デフォルトの名無しさん
09/03/04 13:10:25
>>160
ブランチでの作業が完了してtagsに移動させた時とかに、
自動で追いかけられるとうっかりtagsで作業する人が出てきそう。

ディレクトリ名の変更って頻繁にあるもんじゃないから、
確認の意味でも現状でいいんじゃないかと思う。

164:デフォルトの名無しさん
09/03/04 18:29:48
たしかにそういう危険はありますね、自動的に追跡されると

165:デフォルトの名無しさん
09/03/04 19:53:07
自分の知らないところで何かが行われるのは気持ち悪い。
何かが起こってないか、定期的にチェックする必要があるから。

166:86
09/03/04 23:12:41
リポジトリやディリクトリの移動をしたときにsvn::externalsを一括修正するスクリプトが欲しくなることはある。

167:デフォルトの名無しさん
09/03/05 09:18:02
svn log って過去方向にはコピーなども追跡して
取得してくれるけど、未来方向にそのリビジョンの
発展を知ることはできないのかな？

168:デフォルトの名無しさん
09/03/05 12:25:26
TortoiseSVN 1.5.8, Build 15348であるフォルダを追加した時、
フォルダしか追加されなくて、そのフォルダ配下にあるソースとかが
追加されなくなっちゃったんだけど、仕様変わったの？

169:デフォルトの名無しさん
09/03/05 12:39:46
>>168
どうやって追加した？

170:デフォルトの名無しさん
09/03/05 13:24:59
>>169
複数のディレクトリを選択した状態で右クリック→追加

丁度今日になってバージョンを上げたんだけど、
1.5.6（7だったかも）の時はこのやり方でディレクトリ内の
ソースとかも追加されてた

171:167
09/03/05 13:43:44
ふと思いついたんだけど，リポジトリ内には copyfrom しか
格納されていないわけだし，複数のディレクトリにコピーされる
可能性もあるわけだから単純にそんな機能作れないよなぁ．

とりあえず自分で pysvn でもつかって
追跡するスクリプト書いてみる．

172:デフォルトの名無しさん
09/03/05 13:44:28
と書いていたら1.5.9が出ていたみたいなのでうｐしてきますねorz
HPには1.6.0なんてのも見えますね・・

173:デフォルトの名無しさん
09/03/05 13:48:07
Version 1.5.9
- BUG: Broken registry settings may prevent Check for Modifications dialog
from showing up. (Stefan Fuhrmann)
- BUG: Missing columns when copying to clipboard in Check for Modifications
dialog. (Stefan Fuhrmann)
- BUG: Showing Log for deleted paths should not trigger "go offline? dialog.
(Stefan Fuhrmann)
- BUG: Line endings lost in TortoiseMerge when using "use whole file".
(Stefan)

174:デフォルトの名無しさん
09/03/05 14:12:31
>>171
無理でしょ。よく考えてみなよ。

175:167
09/03/05 15:53:38
>>174
確かに簡単には無理っぽい
ダンプから抽出するスクリプトは書いた．
単に copy と add のアクションが同じパスで
ペアで出現しているのを抽出するだけだけど．

URLﾘﾝｸ(svn.haxx.se)
copyto があったらいいよなっていう話題は
出てるみたいだけど，実装されるのはまだまだ先だろうなぁ．

176:デフォルトの名無しさん
09/03/05 19:05:07
>>175
tortoiseSVNのりビジョングラフはどう？

177:デフォルトの名無しさん
09/03/06 04:51:22
そういう話なのか？

178:デフォルトの名無しさん
09/03/06 08:18:35
リビジョングラフでやっているのは svn log -v / で表示される履歴を繋ぎ合わせているの？

179:デフォルトの名無しさん
09/03/06 08:36:47
分岐されてる状況が見たいんじゃないのか？

180:デフォルトの名無しさん
09/03/06 09:30:08
未来方向にじゃなかったっけ？

181:デフォルトの名無しさん
09/03/07 08:50:01
TortoiseSVNやsvnコマンドで svn+ssh によるアクセスをした時、
サーバ側では svnserve -t が実行されるのが普通だと思いますが、
これを変えることって出来るのでしょうか？たとえばルートを
変えたいとか。

もちろんサーバ側の authorized_keys に command= を指定する
ことで強制することはできると思うのですが、そうではなくて
クライアント側で設定できないものでしょうか？

182:デフォルトの名無しさん
09/03/07 08:54:57
C:\Users\Myname\.subversion\config
のようなファイルは、TortoiseSVN も見に行っているのでしょうか？

TortoiseSVN 以外にコマンドライン版のSubversionも
インストールして使っていたために、混在してます。

183:182
09/03/07 09:31:30
C:\Users\Myname\.subversion\config
ではなくて
C:\Users\Takashi\AppData\Roaming\Subversion\config
でした。

184:デフォルトの名無しさん
09/03/07 10:18:14
やぁたかし君

185:デフォルトの名無しさん
09/03/07 11:44:01
いや実際のところは、kenji でも chimporoh でもいいんですけどね。

186:デフォルトの名無しさん
09/03/07 14:54:45
NEC-PCuser だろフツー

187:デフォルトの名無しさん
09/03/07 15:03:15
ふつーGuest User

188:デフォルトの名無しさん
09/03/07 23:07:44
svnadmin hotcopyでのバックアップですが、
バックアップ先に前回のバックアップが残ったままのフォルダを
指定して再度実行した場合、正常なバックアップは取れるでしょうか？
もちろんバックアップ元は同じリポジトリです。（リビジョンは進行します）
それともバックアップ先を毎回消す必要があるでしょうか？

189:デフォルトの名無しさん
09/03/07 23:13:11
subversionをバージョンアップする際に、
リポジトリはそのままでバージョンアップ可能ですか？
事前にダンプしておいて、バージョンアップ後に取り込みとか必要？

190:デフォルトの名無しさん
09/03/07 23:49:59
>189
都度リリースノート読むのがベスト。

BDB の時は、パッケージの BDB 自体のバージョンが上がった場合などに、
dump/load が必要になる場合がある。
FSFS の場合は基本的に大丈夫。
ただし、リポジトリフォーマットのバージョンを上げないと新しい機能が
使えない場合などがある。
1.5 の時は、merge tracking などで必要だった。
dump/load でなくて svnadmin upgrade で(手動だけど)その場で更新は
可能だった。

191:デフォルトの名無しさん
09/03/08 10:19:11
BDBのほうが枯れてて安定しているって記述を
見かけたんですが、それはすごい古いバージョンの
ものでした。いまでもFSFSよりBDBのほうが安定しているんですか？

192:デフォルトの名無しさん
09/03/08 10:40:22
>>191
TortoiseSVNではリポジトリ作成時にBDBの選択肢が出てこなくなってるところから察してください

193:デフォルトの名無しさん
09/03/08 10:54:34
>>190
svnadmin upgrade は簡単なアップグレードだけで、りビジョンを1000ずつフォルダーに分けてくれる機能の変換はしてくれない
その機能を使いたい人はdump/loadする必要がある。

194:デフォルトの名無しさん
09/03/12 17:17:19
svn:ignoreを新規追加されたフォルダに対して自動的に適用するような事って出来ますか？

195:デフォルトの名無しさん
09/03/13 12:11:39
URLﾘﾝｸ(svnbook.red-bean.com)
ここのglobal-ignores参照

196:デフォルトの名無しさん
09/03/13 13:12:59
global-ignoresは自分にしか適用されないじゃん

197:デフォルトの名無しさん
09/03/13 15:32:58
tracと組み合わせて使うことが多いんだけど，
tracのwikiやチケットのデータも管理対象の
subversionリポジトリにぶち込めればいいのに．

とか思うのはあほ？

198:デフォルトの名無しさん
09/03/13 19:30:29
頻繁に更新されるし、検索向きとは思えないな。

199:デフォルトの名無しさん
09/03/14 17:35:58
>>197
自分もそう思うからアホじゃないと思う。

いや、自分もアホなのかもしれないが。

200:デフォルトの名無しさん
09/03/14 19:44:36
tracをいじって、DBが更新される度に、
DBのダンプをリポジトリに突っ込むとかしたらどうだろうか。

201:デフォルトの名無しさん
09/03/21 01:13:09
svnサーバを構築しようとしてます。初期設定ファイルをほぼそのまま使用し、現在、httpでならcoやciができます。
セキュアな通信をしたく、sshでの認証を入れようと思い、SSLRequireSSLを使おうとしました。

<Location /repos>
DAV svn
SVNParentPath /var/www/svn

<LimitExcept GET PROPFIND OPTIONS REPORT>
SSLRequireSSL
</LimitExcept>
</Location>

これでhttpdの再起動は成功するのですが、coなどが出来なくなります。
coしようとした際のエラーは以下です。
svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for （チェックアウトしようとしたuri）
サーバでsshdは起動しています。動かない原因を教えてもらえませんか？

202:デフォルトの名無しさん
09/03/21 11:18:41
1.6.0リリース

203:デフォルトの名無しさん
09/03/21 11:19:06
↑あ、>>201とは関係ないです

204:デフォルトの名無しさん
09/03/21 12:54:20
なんか
2009/03/19 Subversion 1.6.0 Release Candidate 4 Released
が切ない

205:デフォルトの名無しさん
09/03/21 17:21:39
>>201
まて、sshで通信するならapacheは全く関係ないぞ?

206:デフォルトの名無しさん
09/03/22 02:45:19
TortoiseSVN 1.6.0 release age
URLﾘﾝｸ(tortoisesvn.net)

207:デフォルトの名無しさん
09/03/23 10:32:14
まだRC4か
SVN1.6は1.5と比べて何が変わるのやら

208:デフォルトの名無しさん
09/03/23 10:51:01
>>207
URLﾘﾝｸ(subversion.tigris.org)

209:デフォルトの名無しさん
09/03/23 10:58:27
英語分かんない＞＜

210:デフォルトの名無しさん
09/03/23 11:05:26
同じく。先生翻訳plz

211:デフォルトの名無しさん
09/03/23 11:21:16
>>まだRC4か
普通に1.6リリースされてるじゃん

212:デフォルトの名無しさん
09/03/23 11:42:43
TortoiseSVNを1.6にしてみたけど、Bug-IDって所のBの文字が文字化けしてる
俺だけかもしれないけど

213:デフォルトの名無しさん
09/03/23 11:46:59
ログメッセージの画面にあるやつなら、うちもそうなる。

214:デフォルトの名無しさん
09/03/23 13:10:01
>>210
URLﾘﾝｸ(www.excite-webtl.jp)

215:デフォルトの名無しさん
09/03/23 13:29:50
Google翻訳の方がまだ意味が通る翻訳の気がする

216:デフォルトの名無しさん
09/03/23 14:25:14
転覆1.6

217:デフォルトの名無しさん
09/03/23 14:27:38
>>214
先生、暗号のようで分かりません＞＜

218:デフォルトの名無しさん
09/03/24 00:27:18
ほらよ、乞食ども。

Subversion 1.6 の新規項目

・認証用データの取り扱いの改善
　平文で保存する前の警告、KWallet や GNOME Keyring へのパスワードの保存
　SSL クライアント証明書のパスフレーズの保存のサポート
・リポジトリルートからの相対URL
　^/ でリポジトリルートを意味する
・svn:externals の機能向上
　ファイルに対する svn:externals のサポート、クウォートのサポート等
・ツリーコンフリクトの検出
　ファイル内容だけでなく、ファイルの有無も考慮したコンフリクト
　(例：ローカルで修正したファイルに対するリモートでの削除等)
・ファイルシステムの使用量の改善
　Berkeley DB、FSFS の双方とも使用量削減
・ctypes による Python バインディング
・対話的なコンフリクト解決の改善
　dc(コンフリクトの表示), mc(コンフリクトに対してローカルを選択),
　tc(コンフリクトに対してリモートを選択)オプションの追加
・ディレクトリの working copy からの除外指定
　(ref. URLﾘﾝｸ(blogs.open.collab.net) )
・svnserve のログサポート
・履歴を調べるための新しい公開 HTTP URI 構文
　URLﾘﾝｸ(example.com) で revision 20 を参照可能
・コマンドラインクライアントの改善
　色々。
　特に大きいものとして、log に対して複数リビジョンが指定可能になったことと、
　--trust-server-cert オプションの追加。
・API 変更、改善、および多数の言語バインディングが動作
・65以上のバグフィックス、機能向上。

219:デフォルトの名無しさん
09/03/24 00:42:07
1.5 と互換性無いの？
亀が 1.6 で
Eclipse の subclipse が 1.5 だとダメなんじゃないの？
アップデートするのが怖い・・・

220:デフォルトの名無しさん
09/03/24 00:48:13
ワーキングコピーの形式がまた変わった。
よって、1.4→1.5の時と同じ注意が必要。
なお、TortoiseSVNとSubclipseは両方とも最新版で1.6対応してる。
SubversiveとAnkhSVNは調べてない。

221:デフォルトの名無しさん
09/03/24 01:01:55
>>218
GJ

222:デフォルトの名無しさん
09/03/24 01:18:43
えっ？Subclipseの最新版って？？？？

おお～！
eclipse のソフトウエア更新のURLを
URLﾘﾝｸ(subclipse.tigris.org)
にしたままだった。
URLﾘﾝｸ(subclipse.tigris.org)
にしたら最新版キター！

223:デフォルトの名無しさん
09/03/24 11:18:57
未だにexternalsの使い方が良く分からない
クライアント、サーバ、共通で使うアセンブリファイルとかあるから
重複管理したくないんだけど、こういうのでexternalsは使うのだろうか

224:デフォルトの名無しさん
09/03/25 18:00:57
worst practicesは、どこかで見たことありますけど、
Best practiceまとめたサイトとかありませんか？

subversionを実際にプロジェクトで使おうと思っているのですが、
1つのリポジトリに何を入れるべきかとか、
どういう単位でtrunkとbranchを分けたらよいとか、ぜんぜんわからないので。

たとえば5,6人くらいで半年のプロジェクト(仕事のプロジェクト)で、
OSなしの組み込みプログラムいくつかと、それと通信するWinのプログラム
DLLと、exeをそれぞれいくつかを、開発する。みたいな場合で、
それぞれをどうやって管理するとよいのか。とか、参考になるような
情報を求めています。

225:デフォルトの名無しさん
09/03/26 00:15:09
>>223
そだよ

226:デフォルトの名無しさん
09/03/26 00:26:43
>>224
とりえず適当なプロジェクト単位でtrunkを作る。makefileとかソリューションとか。
trunkは共有できる。いきなりtrunkにコミットするのは怖いからbranchを作って徹底的に試験してからtrunkにマージする。
trunkの分け方が使いづらいと思ったらいつでも移動できるし、戻したいと思えばいつでも戻せるし。
あんまり考えすぎる前に使ってみるのがよろしい。

227:デフォルトの名無しさん
09/03/26 11:58:58
>>226
trunkに恒常的にコミットしないのは一般的じゃないな。
基本trunkにコミットで、
テストが終わったとかリリースしたとかのイベントの度に
tagsにコピー、が一般的じゃね？

trunkは怖くて当然。
テスト済みの不安のないソースはtagsから取る、がうちの流儀。

228:デフォルトの名無しさん
09/03/26 13:09:25
trunkが常に壊れないようにするために、>>226のやり方は一般的だよ

というかbranchesはそういう使い方をするためにある

229:デフォルトの名無しさん
09/03/26 13:29:32
うちでは、
trunk・・・　常に最新、ビルドは通るが不安定
tags・・・　ちゃんとバージョンをつけてリリースした時の各状態
branches・・・まとまった機能追加などで、他に影響を及ぼさないで
　　　　　　　　　ごちょごちょやりたい時にブランチ作成
　　　　　　　　　（しかしなるべく早くtrunkへマージ）
ってやってる。

230:デフォルトの名無しさん
09/03/26 13:49:19
うちもtrunkは容赦なくコミットされていくよ
trunkが壊れると困る！みたいな意見は出ない

231:デフォルトの名無しさん
09/03/26 14:14:11
業務終わりに出来てようがいまいがとりあえずコミットして帰る人とか、
何か勘違いしてる人がいたら、その人限定で枝をあげて、
「trunkにはコミットしないように」って厳命する。

232:デフォルトの名無しさん
09/03/26 14:16:57
そんな窮屈なやり方を強制させるんならおとなしくMercurialなり何なりにさせろよ

233:デフォルトの名無しさん
09/03/26 14:38:49
>>228
apache.orgやsourceforge.netのいくつかのプロジェクトを見る限り、
>>226,228の方が少数派だな。
というかそうやってるところってどこにある？

234:デフォルトの名無しさん
09/03/26 15:15:46
こういう流れを待っていた
他所がどんな風にまわしてるかってあんましらないしな

235:231
09/03/26 17:07:11
>>232
そういう人には業務させてあげているだけです。
決してtrunkにはマージされないですよ？
居なくなるまで仕事させとかないわけにはいかないので。

236:デフォルトの名無しさん
09/03/26 17:36:42
そんな指示を出す前に、正しいコミットルールを指導してやれよ。

237:デフォルトの名無しさん
09/03/26 23:44:38
>>231
本末転倒すぎてありえないわ
あほな運用だなぁ

238:デフォルトの名無しさん
09/03/27 00:22:17
すべてtrunkでいいだろ。
何のための履歴管理だｗ

239:デフォルトの名無しさん
09/03/27 01:16:28
実験的な実装したいときはbranch切るけどな。

240:デフォルトの名無しさん
09/03/27 08:27:30
すべてtrunkってｗｗｗ
個人開発に毛が生えた程度でならそれで済むかもしれんけどｗｗ

241:デフォルトの名無しさん
09/03/27 10:16:00
>>240
Subversion 本体の開発は基本的に trunk にまず全部突っ込む形なわけだけど、
それも「個人開発に毛が生えた程度」だと思ってるの？

242:デフォルトの名無しさん
09/03/27 10:43:00
trunkに制限かけるんなら、おとなしくsvk使わせなさいよ

243:デフォルトの名無しさん
09/03/27 11:09:20
いやほら、きっと「branchで開発するのが当然で、trunkに突っ込むのは馬鹿」って教育を受けてきたんだよ。
某元死刑囚みたいに外の世界を知るまでそれ以外の発想ができなくなるのも仕方ないよね。

244:デフォルトの名無しさん
09/03/27 11:59:42
なんか熱くなった上に自演してるやつまでいるな

245:デフォルトの名無しさん
09/03/27 12:14:21
>>241
「基本的」には確かにそうだね。
でも、その「基本的」な使い方だけですべて済んじゃう（すべてtrunkでいい）
と言ってのけたのを指して、個人開発に毛が生えた程度のことしかやってないんだなと
判断されたわけだ。

246:デフォルトの名無しさん
09/03/27 12:22:19
この手の運用方法で罵り合う連中こそアホだろ
不毛も良いとこ

247:デフォルトの名無しさん
09/03/27 12:26:19
「すべてtrunk」を「trunkだけで十分、tagsもbranchesもイラネ」と捉えるのは
拡大解釈が過ぎる。

248:デフォルトの名無しさん
09/03/27 12:26:58
すべてtrunkはないわー
それこそ、何のためのブランチだってのをもっかい入門書読み直してみたらいい
ブランチもタグも、意味なく使われているわけではないでぇー　ほんまやで！

249:デフォルトの名無しさん
09/03/27 12:28:12
むしろほかにどう捉えろと

250:デフォルトの名無しさん
09/03/27 12:40:22
というか、「出来ていまいがtrunkにコミットして帰る」というのが責められるべき点なのでは。

251:デフォルトの名無しさん
09/03/27 12:45:29
それと今の話って関係なくね？

252:デフォルトの名無しさん
09/03/27 12:55:55
ぶっちゃけこういう使い方が正しいなんてのは無いんじゃないの？
trunk安定板にする運用でもリリース準備のたびにbranchでバグフィックス運用でも
まわってるならそれでいいじゃない。

>>231の使えない奴を隔離するために使うってやり方は
おかしいっていうより気持ち悪いけど。

253:デフォルトの名無しさん
09/03/27 12:58:36
pre-commitでそのユーザからコミットが来たらコンパイルさせてエラーになったら弾けば良いんじゃね

254:デフォルトの名無しさん
09/03/27 13:01:43
まあ、確かに規模によっても最適な使い方は変わるだろうし、
これが正解ってものもないわな
>>231みたいに、誰が見てもアレだってのはるかもしれんがｗ
書かれてる人も、>>231自身もね。類は友を呼ぶってやつか？

255:デフォルトの名無しさん
09/03/27 13:12:22
まあどうしてそういう運用してるか、その運用だと何が便利なのかを説明した点だけ
評価出来るかな。説明した内容に誰も同意しなかったがw

256:デフォルトの名無しさん
09/03/27 13:49:14
>>252
>ぶっちゃけこういう使い方が正しいなんてのは無いんじゃないの？

正しくない運用、というのはある。
ビルド出来ないものをコミットする奴は死刑。

257:デフォルトの名無しさん
09/03/27 13:51:49
全てtrunk運用の場合、
trunkにr1000、r1001、r1002、r1003、r1004ってあって、r1001とr1003が糞commitだった場合、
どうやって、r1004からその影響抜くんでしょうか。何かいいやりかたある？
テストだけで糞commitを見切れるもんかな？
branch切ってたら、branchからマージするときだけ検証すればいいけど。
mercurial使うのが正解だとは思う。

258:デフォルトの名無しさん
09/03/27 14:05:06
うちは基本trunkにコミットだけど、
>>257を読んだら、信用できないコミットがしばし起こるという前提なら
普段は個別のbranchにコミットして、テストが済んだらtrunkへマージ、
というのもありな気がしてきた。
うちは目の届く範囲の少人数でやってるせいか、
幸いにして>>257のような状況は経験していない。

話は若干変わるが
TracやRedmineなどのBTSでいうチケットごとにbranch作って、
チケットがクローズしたらマージってのもありか？
いや、そうやってるわけじゃないんだけど。

259:デフォルトの名無しさん
09/03/27 14:49:12
俺は頻繁に（1日に20～30回とか）コミットするので、いつもbranchを使ってる。

次ページ