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/ 175 名前：167 [2009/03/05(木) 15:53:38 ] >>174 確かに簡単には無理っぽい ダンプから抽出するスクリプトは書いた． 単に copy と add のアクションが同じパスで ペアで出現しているのを抽出するだけだけど． svn.haxx.se/users/archive-2007-07/0416.shtml copyto があったらいいよなっていう話題は 出てるみたいだけど，実装されるのはまだまだ先だろうなぁ． 176 名前：デフォルトの名無しさん mailto:sage [2009/03/05(木) 19:05:07 ] >>175 tortoiseSVNのりビジョングラフはどう？ 177 名前：デフォルトの名無しさん mailto:sage [2009/03/06(金) 04:51:22 ] そういう話なのか？ 178 名前：デフォルトの名無しさん [2009/03/06(金) 08:18:35 ] リビジョングラフでやっているのは svn log -v / で表示される履歴を繋ぎ合わせているの？ 179 名前：デフォルトの名無しさん mailto:sage [2009/03/06(金) 08:36:47 ] 分岐されてる状況が見たいんじゃないのか？ 180 名前：デフォルトの名無しさん [2009/03/06(金) 09:30:08 ] 未来方向にじゃなかったっけ？ 181 名前：デフォルトの名無しさん [2009/03/07(土) 08:50:01 ] TortoiseSVNやsvnコマンドで svn+ssh によるアクセスをした時、 サーバ側では svnserve -t が実行されるのが普通だと思いますが、 これを変えることって出来るのでしょうか？たとえばルートを 変えたいとか。 もちろんサーバ側の authorized_keys に command= を指定する ことで強制することはできると思うのですが、そうではなくて クライアント側で設定できないものでしょうか？ 182 名前：デフォルトの名無しさん [2009/03/07(土) 08:54:57 ] C:\Users\Myname\.subversion\config のようなファイルは、TortoiseSVN も見に行っているのでしょうか？ TortoiseSVN 以外にコマンドライン版のSubversionも インストールして使っていたために、混在してます。 183 名前：182 [2009/03/07(土) 09:31:30 ] C:\Users\Myname\.subversion\config ではなくて C:\Users\Takashi\AppData\Roaming\Subversion\config でした。 184 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 10:18:14 ] やぁたかし君 185 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 11:44:01 ] いや実際のところは、kenji でも chimporoh でもいいんですけどね。 186 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 14:54:45 ] NEC-PCuser だろフツー 187 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 15:03:15 ] ふつーGuest User 188 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 23:07:44 ] svnadmin hotcopyでのバックアップですが、 バックアップ先に前回のバックアップが残ったままのフォルダを 指定して再度実行した場合、正常なバックアップは取れるでしょうか？ もちろんバックアップ元は同じリポジトリです。（リビジョンは進行します） それともバックアップ先を毎回消す必要があるでしょうか？ 189 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 23:13:11 ] subversionをバージョンアップする際に、 リポジトリはそのままでバージョンアップ可能ですか？ 事前にダンプしておいて、バージョンアップ後に取り込みとか必要？ 190 名前：デフォルトの名無しさん mailto:sage [2009/03/07(土) 23:49:59 ] >189 都度リリースノート読むのがベスト。 BDB の時は、パッケージの BDB 自体のバージョンが上がった場合などに、 dump/load が必要になる場合がある。 FSFS の場合は基本的に大丈夫。 ただし、リポジトリフォーマットのバージョンを上げないと新しい機能が 使えない場合などがある。 1.5 の時は、merge tracking などで必要だった。 dump/load でなくて svnadmin upgrade で(手動だけど)その場で更新は 可能だった。 191 名前：デフォルトの名無しさん [2009/03/08(日) 10:19:11 ] BDBのほうが枯れてて安定しているって記述を 見かけたんですが、それはすごい古いバージョンの ものでした。いまでもFSFSよりBDBのほうが安定しているんですか？ 192 名前：デフォルトの名無しさん mailto:sage [2009/03/08(日) 10:40:22 ] >>191 TortoiseSVNではリポジトリ作成時にBDBの選択肢が出てこなくなってるところから察してください 193 名前：デフォルトの名無しさん mailto:sage [2009/03/08(日) 10:54:34 ] >>190 svnadmin upgrade は簡単なアップグレードだけで、りビジョンを1000ずつフォルダーに分けてくれる機能の変換はしてくれない その機能を使いたい人はdump/loadする必要がある。 194 名前：デフォルトの名無しさん mailto:sage [2009/03/12(木) 17:17:19 ] svn:ignoreを新規追加されたフォルダに対して自動的に適用するような事って出来ますか？ 195 名前：デフォルトの名無しさん mailto:sage [2009/03/13(金) 12:11:39 ] ttp://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1.3.2 ここのglobal-ignores参照 196 名前：デフォルトの名無しさん mailto:sage [2009/03/13(金) 13:12:59 ] global-ignoresは自分にしか適用されないじゃん 197 名前：デフォルトの名無しさん [2009/03/13(金) 15:32:58 ] tracと組み合わせて使うことが多いんだけど， tracのwikiやチケットのデータも管理対象の subversionリポジトリにぶち込めればいいのに． とか思うのはあほ？ 198 名前：デフォルトの名無しさん mailto:sage [2009/03/13(金) 19:30:29 ] 頻繁に更新されるし、検索向きとは思えないな。 199 名前：デフォルトの名無しさん mailto:sage [2009/03/14(土) 17:35:58 ] >>197 自分もそう思うからアホじゃないと思う。 いや、自分もアホなのかもしれないが。 200 名前：デフォルトの名無しさん mailto:sage [2009/03/14(土) 19:44:36 ] tracをいじって、DBが更新される度に、 DBのダンプをリポジトリに突っ込むとかしたらどうだろうか。 201 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/03/21(土) 11:18:41 ] 1.6.0リリース 203 名前：デフォルトの名無しさん mailto:sage [2009/03/21(土) 11:19:06 ] ↑あ、>>201とは関係ないです 204 名前：デフォルトの名無しさん mailto:sage [2009/03/21(土) 12:54:20 ] なんか 2009/03/19 Subversion 1.6.0 Release Candidate 4 Released が切ない 205 名前：デフォルトの名無しさん mailto:sage [2009/03/21(土) 17:21:39 ] >>201 まて、sshで通信するならapacheは全く関係ないぞ? 206 名前：デフォルトの名無しさん [2009/03/22(日) 02:45:19 ] TortoiseSVN 1.6.0 release age tortoisesvn.net/node/364 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

---

---

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

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