- 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/
- 207 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 10:32:14 ]
- まだRC4か
SVN1.6は1.5と比べて何が変わるのやら
- 208 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 10:51:01 ]
- >>207
ttp://subversion.tigris.org/svn_1.6_releasenotes.html
- 209 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 10:58:27 ]
- 英語分かんない＞＜
- 210 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 11:05:26 ]
- 同じく。先生翻訳plz
- 211 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 11:21:16 ]
- >>まだRC4か
普通に1.6リリースされてるじゃん
- 212 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 11:42:43 ]
- TortoiseSVNを1.6にしてみたけど、Bug-IDって所のBの文字が文字化けしてる
俺だけかもしれないけど
- 213 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 11:46:59 ]
- ログメッセージの画面にあるやつなら、うちもそうなる。
- 214 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 13:10:01 ]
- >>210
ttp://www.excite-webtl.jp/world/english/web/?wb_url=http%3A%2F%2Fsubversion.tigris.org%2Fsvn_1.6_releasenotes.html&wb_lp=ENJA
- 215 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 13:29:50 ]
- Google翻訳の方がまだ意味が通る翻訳の気がする
- 216 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 14:25:14 ]
- 転覆1.6
- 217 名前：デフォルトの名無しさん mailto:sage [2009/03/23(月) 14:27:38 ]
- >>214
先生、暗号のようで分かりません＞＜
- 218 名前：デフォルトの名無しさん mailto:sage [2009/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. blogs.open.collab.net/svn/2009/03/sparse-directories-now-with-exclusion.html )
・svnserve のログサポート
・履歴を調べるための新しい公開 HTTP URI 構文
example.com/repos/file?r=20 で revision 20 を参照可能
・コマンドラインクライアントの改善
色々。
特に大きいものとして、log に対して複数リビジョンが指定可能になったことと、
--trust-server-cert オプションの追加。
・API 変更、改善、および多数の言語バインディングが動作
・65以上のバグフィックス、機能向上。
- 219 名前：デフォルトの名無しさん mailto:sage [2009/03/24(火) 00:42:07 ]
- 1.5 と互換性無いの？
亀が 1.6 で
Eclipse の subclipse が 1.5 だとダメなんじゃないの？
アップデートするのが怖い・・・
- 220 名前：デフォルトの名無しさん mailto:sage [2009/03/24(火) 00:48:13 ]
- ワーキングコピーの形式がまた変わった。
よって、1.4→1.5の時と同じ注意が必要。
なお、TortoiseSVNとSubclipseは両方とも最新版で1.6対応してる。
SubversiveとAnkhSVNは調べてない。
- 221 名前：デフォルトの名無しさん mailto:sage [2009/03/24(火) 01:01:55 ]
- >>218
GJ
- 222 名前：デフォルトの名無しさん mailto:sage [2009/03/24(火) 01:18:43 ]
- えっ？Subclipseの最新版って？？？？
おお〜！
eclipse のソフトウエア更新のURLを
subclipse.tigris.org/update_1.4.x
にしたままだった。
subclipse.tigris.org/update_1.6.x
にしたら最新版キター！
- 223 名前：デフォルトの名無しさん mailto:sage [2009/03/24(火) 11:18:57 ]
- 未だにexternalsの使い方が良く分からない
クライアント、サーバ、共通で使うアセンブリファイルとかあるから
重複管理したくないんだけど、こういうのでexternalsは使うのだろうか
- 224 名前：デフォルトの名無しさん [2009/03/25(水) 18:00:57 ]
- worst practicesは、どこかで見たことありますけど、
Best practiceまとめたサイトとかありませんか？
subversionを実際にプロジェクトで使おうと思っているのですが、
1つのリポジトリに何を入れるべきかとか、
どういう単位でtrunkとbranchを分けたらよいとか、ぜんぜんわからないので。
たとえば5,6人くらいで半年のプロジェクト(仕事のプロジェクト)で、
OSなしの組み込みプログラムいくつかと、それと通信するWinのプログラム
DLLと、exeをそれぞれいくつかを、開発する。みたいな場合で、
それぞれをどうやって管理するとよいのか。とか、参考になるような
情報を求めています。
- 225 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 00:15:09 ]
- >>223
そだよ
- 226 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 00:26:43 ]
- >>224
とりえず適当なプロジェクト単位でtrunkを作る。makefileとかソリューションとか。
trunkは共有できる。いきなりtrunkにコミットするのは怖いからbranchを作って徹底的に試験してからtrunkにマージする。
trunkの分け方が使いづらいと思ったらいつでも移動できるし、戻したいと思えばいつでも戻せるし。
あんまり考えすぎる前に使ってみるのがよろしい。
- 227 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 11:58:58 ]
- >>226
trunkに恒常的にコミットしないのは一般的じゃないな。
基本trunkにコミットで、
テストが終わったとかリリースしたとかのイベントの度に
tagsにコピー、が一般的じゃね？
trunkは怖くて当然。
テスト済みの不安のないソースはtagsから取る、がうちの流儀。
- 228 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 13:09:25 ]
- trunkが常に壊れないようにするために、>>226のやり方は一般的だよ
というかbranchesはそういう使い方をするためにある
- 229 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 13:29:32 ]
- うちでは、
trunk・・・ 常に最新、ビルドは通るが不安定
tags・・・ ちゃんとバージョンをつけてリリースした時の各状態
branches・・・ まとまった機能追加などで、他に影響を及ぼさないで
ごちょごちょやりたい時にブランチ作成
（しかしなるべく早くtrunkへマージ）
ってやってる。
- 230 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 13:49:19 ]
- うちもtrunkは容赦なくコミットされていくよ
trunkが壊れると困る！みたいな意見は出ない
- 231 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 14:14:11 ]
- 業務終わりに出来てようがいまいがとりあえずコミットして帰る人とか、
何か勘違いしてる人がいたら、その人限定で枝をあげて、
「trunkにはコミットしないように」って厳命する。
- 232 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 14:16:57 ]
- そんな窮屈なやり方を強制させるんならおとなしくMercurialなり何なりにさせろよ
- 233 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 14:38:49 ]
- >>228
apache.orgやsourceforge.netのいくつかのプロジェクトを見る限り、
>>226,228の方が少数派だな。
というかそうやってるところってどこにある？
- 234 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 15:15:46 ]
- こういう流れを待っていた
他所がどんな風にまわしてるかってあんましらないしな
- 235 名前：231 mailto:sage [2009/03/26(木) 17:07:11 ]
- >>232
そういう人には業務させてあげているだけです。
決してtrunkにはマージされないですよ？
居なくなるまで仕事させとかないわけにはいかないので。
- 236 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 17:36:42 ]
- そんな指示を出す前に、正しいコミットルールを指導してやれよ。
- 237 名前：デフォルトの名無しさん mailto:sage [2009/03/26(木) 23:44:38 ]
- >>231
本末転倒すぎてありえないわ
あほな運用だなぁ
- 238 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 00:22:17 ]
- すべてtrunkでいいだろ。
何のための履歴管理だｗ
- 239 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 01:16:28 ]
- 実験的な実装したいときはbranch切るけどな。
- 240 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 08:27:30 ]
- すべてtrunkってｗｗｗ
個人開発に毛が生えた程度でならそれで済むかもしれんけどｗｗ
- 241 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 10:16:00 ]
- >>240
Subversion 本体の開発は基本的に trunk にまず全部突っ込む形なわけだけど、
それも「個人開発に毛が生えた程度」だと思ってるの？
- 242 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 10:43:00 ]
- trunkに制限かけるんなら、おとなしくsvk使わせなさいよ
- 243 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 11:09:20 ]
- いやほら、きっと「branchで開発するのが当然で、trunkに突っ込むのは馬鹿」って教育を受けてきたんだよ。
某元死刑囚みたいに外の世界を知るまでそれ以外の発想ができなくなるのも仕方ないよね。
- 244 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 11:59:42 ]
- なんか熱くなった上に自演してるやつまでいるな
- 245 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:14:21 ]
- >>241
「基本的」には確かにそうだね。
でも、その「基本的」な使い方だけですべて済んじゃう（すべてtrunkでいい）
と言ってのけたのを指して、個人開発に毛が生えた程度のことしかやってないんだなと
判断されたわけだ。
- 246 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:22:19 ]
- この手の運用方法で罵り合う連中こそアホだろ
不毛も良いとこ
- 247 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:26:19 ]
- 「すべてtrunk」を「trunkだけで十分、tagsもbranchesもイラネ」と捉えるのは
拡大解釈が過ぎる。
- 248 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:26:58 ]
- すべてtrunkはないわー
それこそ、何のためのブランチだってのをもっかい入門書読み直してみたらいい
ブランチもタグも、意味なく使われているわけではないでぇー ほんまやで！
- 249 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:28:12 ]
- むしろほかにどう捉えろと
- 250 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:40:22 ]
- というか、「出来ていまいがtrunkにコミットして帰る」というのが責められるべき点なのでは。
- 251 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:45:29 ]
- それと今の話って関係なくね？
- 252 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:55:55 ]
- ぶっちゃけこういう使い方が正しいなんてのは無いんじゃないの？
trunk安定板にする運用でもリリース準備のたびにbranchでバグフィックス運用でも
まわってるならそれでいいじゃない。
>>231の使えない奴を隔離するために使うってやり方は
おかしいっていうより気持ち悪いけど。
- 253 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 12:58:36 ]
- pre-commitでそのユーザからコミットが来たらコンパイルさせてエラーになったら弾けば良いんじゃね
- 254 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 13:01:43 ]
- まあ、確かに規模によっても最適な使い方は変わるだろうし、
これが正解ってものもないわな
>>231みたいに、誰が見てもアレだってのはるかもしれんがｗ
書かれてる人も、>>231自身もね。類は友を呼ぶってやつか？
- 255 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 13:12:22 ]
- まあどうしてそういう運用してるか、その運用だと何が便利なのかを説明した点だけ
評価出来るかな。説明した内容に誰も同意しなかったがw
- 256 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 13:49:14 ]
- >>252
>ぶっちゃけこういう使い方が正しいなんてのは無いんじゃないの？
正しくない運用、というのはある。
ビルド出来ないものをコミットする奴は死刑。
- 257 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 13:51:49 ]
- 全てtrunk運用の場合、
trunkにr1000、r1001、r1002、r1003、r1004ってあって、r1001とr1003が糞commitだった場合、
どうやって、r1004からその影響抜くんでしょうか。何かいいやりかたある？
テストだけで糞commitを見切れるもんかな？
branch切ってたら、branchからマージするときだけ検証すればいいけど。
mercurial使うのが正解だとは思う。
- 258 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 14:05:06 ]
- うちは基本trunkにコミットだけど、
>>257を読んだら、信用できないコミットがしばし起こるという前提なら
普段は個別のbranchにコミットして、テストが済んだらtrunkへマージ、
というのもありな気がしてきた。
うちは目の届く範囲の少人数でやってるせいか、
幸いにして>>257のような状況は経験していない。
話は若干変わるが
TracやRedmineなどのBTSでいうチケットごとにbranch作って、
チケットがクローズしたらマージってのもありか？
いや、そうやってるわけじゃないんだけど。
- 259 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 14:49:12 ]
- 俺は頻繁に（1日に20〜30回とか）コミットするので、いつもbranchを使ってる。
- 260 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 14:50:48 ]
- >>258
> チケットがクローズしたらマージってのもありか？
branchをそのままリリースするならあり。
マージしたtrunkをリリースするなら、マージした物に対してテストしないと無意味。
- 261 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 15:14:10 ]
- >>257
branchからマージするときに検証したとしても
そのときの検証だけで糞commitを見切れるもんなの?
その主張の本質はbranchの有無はあまり関係なくて
チェックを多くすれば間違いが減る(かもしれない)
という当たり前のことじゃね。
- 262 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 15:51:40 ]
- たしかにそうだな。
っていうかデグレをなくすにはどうしたらいい？っていう
もうちょっと一般的な命題なんじゃね？それって。
ところで>>257の言うところの糞コミットってのは
仕様上ちゃんとしたものだけど、実装の仕方やコードの品質がゴミなコードってことかね。
そういうのだったらコードレビューでもするしかないような。
- 263 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 16:27:37 ]
- レビュー体制にもよるよなあ。
コミット前に必ずレビューするのか本流っぽいところにマージする時だけレビューするのか。
オープンソースのプロジェクトにかかわったことないんだけど
そこらへんどうしてるんだろ。
- 264 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 17:21:34 ]
- デグレの使い方が間違っとる
- 265 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 18:12:43 ]
- ブランチ→修正→検証→コミットのサイクルを繰り返してtrunkの安定度が少しずつ上がるんじゃないか？
- 266 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 18:14:01 ]
- >>265間違えた
trunkからブランチ→修正→検証→trunkにマージのサイクルを繰り返してtrunkの安定度が少しずつ上がるんじゃないか？
- 267 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 18:27:09 ]
- trunk: 最新版
branch: trunkからリリース準備単位で派生
tag: branchからリリース完成単位で派生、基本ここは修正しない(bugfixはbranchで)
ってのがsubversionのドキュメントでサンプルに出されてた使い方だったかと。
自分はこれに加えて実験的なことしたい時もbranchを切るやり方でやってる。
少人数の上仕事で使ってるわけじゃないからこれでべつにいっかなーと。
- 268 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 18:40:26 ]
- >>267
apacheとかeclipseとか、
メジャーなオープンソースプロジェクトはだいたいそんな感じだね。
- 269 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 18:45:23 ]
- Redmine使ってるんだが、ブランチ切って作業すると
プロジェクトの指してるリポジトリと合わなくなって困る
なんとかならんのか
- 270 名前：デフォルトの名無しさん mailto:sage [2009/03/27(金) 20:51:09 ]
- >>267
それで困ることってあるんかな
- 271 名前：デフォルトの名無しさん mailto:sage [2009/03/29(日) 13:00:46 ]
- うちは、trunkにコミットしたものは1分後にHudsonがビルド〜テストを開始するので、
- Hudsonで扱って欲しいもの->trunkへ
-- ビルドエラーが起こるソースコードをコミットすると、Hudsonのログでさらし者。
-- テスト結果もHudsonのログに残す。
- 実験的なもの（Hudson側の設定を行っていない）や大改変中でビルドエラーがあるもの ->branchesへ
- リリースやマイルストーンごと区切り（テスト区が関わる）-> tagsへ（tagsにsvn copy出来るのは中核メンバー数人だけに制限）
- 272 名前：デフォルトの名無しさん mailto:sage [2009/03/29(日) 16:23:41 ]
- Hudsonって何？
- 273 名前：デフォルトの名無しさん mailto:sage [2009/03/29(日) 16:30:37 ]
- ググりゃすぐでてくるがな。
- 274 名前：デフォルトの名無しさん mailto:sage [2009/03/29(日) 16:31:21 ]
- やらなきゃ
- 275 名前：デフォルトの名無しさん mailto:sage [2009/03/29(日) 17:19:38 ]
- >>272
ttp://gihyo.jp/dev/feature/01/hudson/0001
- 276 名前：デフォルトの名無しさん mailto:sage [2009/03/29(日) 22:45:51 ]
- ぐぐった。
img2.timeinc.net/people/i/2006/celebdatabase/katehudson/kate_hudson1_300_400.jpg
- 277 名前：デフォルトの名無しさん mailto:sage [2009/03/30(月) 10:53:06 ]
- 担当が突然消える場合(病気、事故、失踪)に備えて、個人用ブランチに毎日コミットさせてる。
- 278 名前：デフォルトの名無しさん mailto:sage [2009/03/30(月) 11:22:21 ]
- まさかとは思うけど、個人的にsvkやgit-svnを使用することを禁止してるところってないよね？
- 279 名前：278 mailto:sage [2009/03/30(月) 20:50:26 ]
- 「個人的に」はわかりにくいか。
社内のSubversionレポジトリへsvkやgit-svnでのアクセスを禁止してるところは…て意味です
- 280 名前：デフォルトの名無しさん mailto:sage [2009/03/30(月) 21:11:18 ]
- 状況によるんでない？
何するツールなのか知った上で禁止してるのか、
知らないからこそ勝手ツールとして禁止してるのか。
個人用のブランチ切れ&守秘義務的に繋った場所での作業Onlyって運用ルールだと
メリットも薄れるだろし。
- 281 名前：デフォルトの名無しさん mailto:sage [2009/03/31(火) 10:42:09 ]
- svkの使用は禁止されてないが
svkからのpushは禁止されてる
- 282 名前：デフォルトの名無しさん [2009/03/31(火) 12:47:13 ]
- あのさ，遠隔地でどうしてもリポジトリにつなげないとき，
ワーキングコピーに対して行った変更を何らかの方法で
（たとえばメールとかで）リポジトリ管理者に
渡して更新してもらうってのは無理？
patch ファイル作ってっていうのがまずはじめに思いつく
方法だけど，プロパティの変更とかそういったものまで
含めた patch ファイルのようなもの（ダンプの一部みたい
なもの）を生成してリポジトリ管理者側で流し込んでもらう
手のは無理だろうか．
ワーキングコピー全体を渡せよってのは，ちょっと規模が
大きくてやりたくない．
- 283 名前：デフォルトの名無しさん mailto:sage [2009/03/31(火) 13:06:17 ]
- 変更(外出)前のワーキングコピーを両方に保存しておいて
ワーキングコピーの差分だけ送る
- 284 名前：デフォルトの名無しさん [2009/03/31(火) 18:28:19 ]
- svnserve って一応認証あるけどやっぱりインターネットに
さらしておくと危険かな？
今のところ安心感をとって ssh+svn でアクセスしてるんだけど．
- 285 名前：デフォルトの名無しさん mailto:sage [2009/03/31(火) 19:25:03 ]
- そりゃまあ普通のプログラムである以上、exploitが見つかったら攻撃されるだろし
必要なIP範囲が決ってるならそれ以外をフィルタリングするぐらいのことはしていいんじゃね？
svnserve内のアクセス権設定がちゃんとしてるのは大前提だよね。
盗聴されるかどうかはsshで繋いでりゃとりあえずは安心だとは思うけど。
- 286 名前：デフォルトの名無しさん mailto:sage [2009/03/31(火) 22:25:56 ]
- FreeBSDはリードオンリーだけどsvn晒してるな。
- 287 名前：デフォルトの名無しさん [2009/04/01(水) 16:36:54 ]
- ActiveDirectoryを使ってユーザーの認証はできたのですが、
ユーザーごとのアクセス制御ができないです。
(ログインすると全てのレポジトリへRead,Writeができてしまう)
AuthzSVNAccessFileを指定するとユーザー名、パスワードの入力後にサーバから切断されてしまいます。
LDAPを使用する場合、個別のアクセス制御などはできないのでしょうか？
参考となるサイト等がありましたら教えてください。
httpd.confの内容::
<Location "/svn/">
DAV svn
SVNParentPath "D:\TracLight\projects\svn"
SVNListParentPath on
AuthType Basic
AuthName "Enter your LDAP ID"
AuthBasicProvider ldap
AuthLDAPBindDN admin@example.com
AuthLDAPBindPassword pass
AuthLDAPURL "ldap://ldap-server:389/dc=sample,dc=com?sAMAccountName?sub?(objectClass=*)"
Require valid-user
AuthzSVNAccessFile "D:\TracLight\projects\svnauthz"
↑この行を追加するとページの読み込みエラーになる
</Location>
- 288 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 10:20:04 ]
- すいません、ブランチについて質問なのですが、
1. ブランチを切る
2. ブランチのみへコミットして、トランクは全くいじらない
3. ブランチの変更をトランクへマージ
このような変更を行ったところ、予想では全くコンフリクトが起こらずスムーズにマージされると思ったのですが、
実際には一部のファイルでコンフリクトが起こりました。（ほとんど自分しか使わないためこういうことがよくあります）
今までブランチをほとんど使ったことがなく、仕組みもよくわかっていないのですが
（いろいろ解説を読んだのですが、いまだによくわからないorz）
これはこういうものなんでしょうか？
そして、ブランチの変更を全面的にコミットするには、
1. .rXXXファイルの内容を元のファイルへ上書き
2. コンフリクトを解消
であっているんでしょうか？それとももっと効率的な方法はありますか？
- 289 名前：デフォルトの名無しさん [2009/04/03(金) 12:29:37 ]
- トランクは全くいじらなければ
（そして他のブランチからのマージもしなければ）
コンフリクトが起きるってことは無いと思うんだけどなぁ．
もしかして古い Subversion クライアントでマージ
トラッキングの機能がない奴を使ってるとか．
- 290 名前：288 mailto:sage [2009/04/03(金) 13:00:54 ]
- >>289
TortoiseSVN, subversive(Eclipseのプラグイン）両方の最新版で試してみましたが、両方ともそうなりました。
subversiveの方では、branchの変更を戻すとき用のメニューである"再統合"を使いましたが、結果は上の通りでした。
- 291 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 14:44:16 ]
- そもそもなぜ衝突が起きるのかを理解してんのかね
- 292 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 14:47:57 ]
- >>288の言ってることが正しいなら、「衝突が起きて当たり前」とは到底思えないが…
- 293 名前：288 mailto:sage [2009/04/03(金) 14:48:48 ]
- >>291
同時に同じファイルの(だいたい）同じ個所を編集して、コミットするからですよね？
その通りなら、絶対同時に編集していない私のケースは、やっぱりおかしいんでしょうか。
- 294 名前：292 mailto:sage [2009/04/03(金) 15:11:20 ]
- >>293
微妙に理解が違うかな。
・trunkで、あるファイルのある場所を更新した。
・branchで、同じファイルの別の場所を更新した。
これを行っていれば、trunkに対しbranchで行った変更をマージすると衝突する可能性がある。
「いつ」変更したかは関係ない。
>>288では
＞2. ブランチのみへコミットして、トランクは全くいじらない
と言っているので、本当にそれが正しいなら衝突は有り得ないと思うんです。
どうして衝突したんだろう。
- 295 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 15:11:51 ]
- コンフリクトマーカーの所見ればいいじゃん。
何で見ないの？
- 296 名前：292 mailto:sage [2009/04/03(金) 15:29:27 ]
- >>295
マーカー見ると、二つのファイルでdiffしたところが示されます。
つまり、
A
B
C
- 297 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 15:32:19 ]
- じゃあ、原因分かるでしょ。
- 298 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 15:34:20 ]
- 差分みりゃわかるわなあ。
- 299 名前：292 mailto:sage [2009/04/03(金) 15:35:42 ]
- すいません、途中で書き込んでしまいました。
マーカー見ると、二つのファイルでdiffしたところが示されます。
つまり、
A
B
C
というファイルを、ブランチで
A
b
C
という風に編集すると、マージしたとき
A
<<<<<< .r2
b
====
B
>>>>>> .r1
C
という風になります。
- 300 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 15:36:30 ]
- 勘だと、
２度目のマージなのに根元からマージした。
もしくは、キーワード置換を有効にしてる。
- 301 名前：292 mailto:sage [2009/04/03(金) 15:38:05 ]
- もしかするとsubversiveを使ってブランチを切ったので、その辺で設定を間違ったのかもしれません。
一度TortoiseSVNのみでブランチを編集するとどうなるか試してみます。
相談を聞いていただきありがとうございました。
- 302 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 16:23:07 ]
- どうでもいいけど、そう言うツールをほいほいとあれこれ使いまくらずに
まずは一つに絞って使えよ
- 303 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 17:04:09 ]
- 行末とか漢字コードとか
- 304 名前：292 mailto:sage [2009/04/08(水) 12:02:20 ]
- すいません、原因がわかりました。
subversiveでブランチを切るとき、ブランチの位置をフルパスで指定していたのですが、
どうやらそのために別のリポジトリへブランチを切ったと判断されていたらしく、
そのために過去の変更履歴が参照されなかったようです。
どうもお騒がせしました。
- 305 名前：デフォルトの名無しさん [2009/04/10(金) 15:07:32 ]
- Subversion 1.6.1 release age
svn.collab.net/repos/svn/tags/1.6.1/CHANGES
- 306 名前：デフォルトの名無しさん [2009/04/11(土) 10:06:12 ]
- TortoiseSVN 1.6.1 release age
sourceforge.net/project/shownotes.php?release_id=674821
- 307 名前：デフォルトの名無しさん [2009/04/11(土) 11:44:17 ]
- ruby binding で
svn ci path_to_project --encoding=UTF-8
相当を行うにはどうすればよいのでしょうか？
ctx = Svn::Client::Context.new()
ctx.auth_baton[Svn::Core::AUTH_PARAM_DEFAULT_USERNAME] = ''
ctx.add_username_provider
ctx.add_simple_provider
ctx.ci(path_to_project)
このようにすると、can't convert native code to 'UTF-8' みたいエラーがでます。
そのため、--eoncoding に相当するようなコードを入れたいのです。
|
 |
