BugTrack/2214 の履歴ソース(No.4)

* Subversion 関連のまとめ [#z91149fa]

- ページ: [[BugTrack2]]
- 投稿者: 名無しさん
- 優先順位: 低
- 状態: 提案
- カテゴリー: その他
- 投稿日: 2007-03-08 (木) 23:48:50
- バージョン: 

#contents

** メッセージ [#fafe145b]

([[開発談義]]より移動)

-svn移行まだですか？ --  &new{2007-01-06 (土) 16:22:29};
--実現可能になった後に、管理上の有効性が見出せないうちは無いでしょうね :) -- [[henoheno]] &new{2007-01-07 (日) 22:44:13};
--具体的には、sf.jpは(sf.netと違い)まだSubversionを完全にサポートしていません。 http://sourceforge.jp/forum/forum.php?forum_id=10564 -- [[henoheno]] &new{2007-01-07 (日) 22:45:44};
--また、開発環境としては今現在cvsで充分に間に合っており、svnに以降するほどの動機が見あたりません。cvsはsvnよりも前から存在するので、利用できる環境はより多いと考えられます。コメント元の方にとっての動機を明確にしていただけますか -- [[henoheno]] &new{2007-01-07 (日) 22:50:28};
---うーん。svnの方が操作がわかりやすい。既に多くのオープンソースなプロジェクトで採用されている((まだCVSなプロジェクトも多いけれど))。ブランチやらタグやらの作成がCVSに比べてかなり素早くできる。一番の理由は、大元がCVSだと先端追っかけてマージしていくのがツールを使ってもかなり面倒。あと、新規の人((人柱、開発者含む))がCVSに比べて先端追っかけるのに必要なもの(前提知識)が少なくて済むと思う。こんな感じです。正式サポートじゃなくても移る価値はあると思いますよ。そのうち正式サポートされるのは確実ですし。 --  &new{2007-01-08 (月) 04:27:20};
--- 単に使い勝手の問題ならsvnに移行してもそう利点はないです。cvsでうまく環境が構築できていないのでは？個人的には必要性があってsvnに全面的に移行しましたが普通にソースを追っかける分にはそれほど違わないですよ。
-- コメントありがとうございます。本件は既存のcvsによる開発体制の運用に関する話題なので、(1) 実際に日々作業を行うプロジェクト開発チームにとって (2)明白な利点があり、(3)それが移行する手間を上回り、 (4) ((既に構築している開発体制を一部再現できないような))欠点が無い事が確認できなければ、リビジョン管理システムを乗り換える理由にはならないのです。導き出すべき結論は、cvsリポジトリの管理者(cvsサーバーの管理者)で、かつsvnリポジトリの管理者(svnサーバーの管理者)でもある方が出すようなものにしなければいけません。 -- [[henoheno]] &new{2007-01-17 (水) 22:40:26};
--- ブランチやタグの速度についてはリポジトリのデータ構造に依存した事を言われているのでしょうから、不思議ではありません。ただ、PukiWikiが取り扱っているファイルの数は問題にならないほど少ないため問題になりません((余談ですがcvsでは、場合によってはtagの代わりにrtagコマンドが使えます))。cvsで先端(HEAD)を追いかける手順が面倒Subversionが楽だ、というのはできればご説明いただきたいです。 -- [[henoheno]] &new{2007-01-17 (水) 23:09:36};
--- cvsで問題だと思っているのは「WinCVSごった煮版」に代わるソリューションが現状見当たらないと思っている点があります。svnが実現しているファイルのmoveについてはコミットログで運用しているので(開発者的には)問題になりません。ディレクトリの扱いについては困っていません。 -- [[henoheno]] &new{2007-01-17 (水) 23:10:16};
--- svnで問題だと思っているのは、ある意味まだ枯れていないという点と、[[cvs2cl>http://pukiwiki.sourceforge.jp/ChangeLog.txt]]相当の出力をどうすれば得られるか現状知らない点、sf.jpのsvリポジトリのバックエンドが何(RDBMSなのか、fsfsなのかというレベルで)か不明で、リポジトリのダンプをこちらで定期的に預かるような事ができるのか不明な点がありますが、最初の一つ以外はいずれ明確になるでしょう。 -- [[henoheno]] &new{2007-01-17 (水) 23:10:59};
-- svnにするかどうか、という話題の一番のポイントはおそらく、一般ユーザーは喜ぶかもしれないけれど、開発者にとっては全然違いが無く、管理者にとっては管理上のリスクが増えるという部分にあるでしょう。 -- [[henoheno]] &new{2007-01-17 (水) 23:13:49};
---「全然違いが無く」？嘘でしょう？違いが「無い」なら直ちに移行出来るハズ。で、ここで言ってる管理者ってのはhenohenoさん自身のことですよね。リスクってなんでしょう？管理の手間のことならむしろsvnの方が少ないような印象です。svnのバックエンドはBDBかfsfsだし。cvs2cl相当の出力は svn log -v で十分間に合うように思います。あーでも、自鯖や仕事で使った経験からなので、sf.jpのことは正直言ってわからんです。まとまりの無い文章ですまん。 --  &new{2007-01-18 (木) 21:19:41};
---あと一個だけ。「(svnが)ある意味枯れてない」ってどういうことでしょう？ --  &new{2007-01-18 (木) 21:21:30};
---一応、調べた。svn2cl.xslってのがあってDebianだとコマンド一発(svn2cl)でChangeLog形式のテキストファイルを作成できるよ。 --  &new{2007-01-18 (木) 21:33:43};
--管理者のことだけ考えずに、ユーザのことも考えてほしいですね。以前ディレクトリ構造が変わったことがあるわけですが、あのときはアップデートに非常に苦労させられました。svn ならファイル名の変更をサポートしているのでかなり楽ができたのではないかと思います。 -- [[o]] &new{2007-01-19 (金) 06:42:34};
---確かにあのときは凄く苦労した覚えがあります。「何でsvnじゃないんだよ」って思いつつ更新作業しました。 --  &new{2007-01-19 (金) 22:47:04};
--henoheno 氏ではないですが、「(svnが)ある意味枯れてない」というのはまだ開発が現役で続いているってことだと思います。つまり、下手をすると仕様までが変わって面倒くさい思いをするというマイナスがあります。でも、だいぶ固まってはいると思うんですけどね。php とかはひどいもんですけど。 -- [[o]] &new{2007-01-19 (金) 06:47:33};
-- svn2cl.xsl の情報ありがとうございます。これのフロントエンドとして svn2cl.sh があるようですね。 -- [[henoheno]] &new{2007-01-22 (月) 00:11:24};
--"ディレクトリ構造が変わった" という件は、2004/08/01 に、各種ライブラリを lib/ 以下に移動させたコミットの事ですね。 -- [[henoheno]] &new{2007-01-22 (月) 00:38:56};
--- 補足: cvsはファイルの移動に関するリビジョン管理をサポートしませんから、"ファイルの削除" と "ファイルの追加" でそれを表現するしかありません。この様な操作をcvsで追随する場合、(仮に関連ファイルを編集していたならば) 移動前のファイルに適用されていた差分を(ファイル直前の状態まで)マージした後、移動後の変更をマージする事になります。 -- [[henoheno]] &new{2007-01-22 (月) 00:39:38};
--- (この特徴を踏まえ)cvs上のファイル移動について、開発者としてやるべき事は、コミットログで 移動元 と 移動先 を明示する事です。管理者としてやるべき事は、コミットメール、cvs2cl、ViewCVSなどのサービスを提供して、マージ作業を支援する環境を提供する事、またHEAD(CVS版)の _ある意味危険な_ 立場を明確にする事です。 -- [[henoheno]] &new{2007-01-22 (月) 00:40:02};
--- こうした運用上のフォローは以前からされていますから、 皆さんの苦労というのが、どんな苦労だったのかをもう少し明確に教えて下さい。cvsのこうした面にある意味不慣れであったという事であれば、理解を深めて道具を便利に使いましょうという話題でしかありません(インフラがsvnであるべきだという主張の裏づけにはなりません)。 -- [[henoheno]] &new{2007-01-22 (月) 00:40:26};
-なぜそれを自動化できるツールがある(svn)と言っているのに手作業の説明をするのでしょう。ソフトウェア開発において自動化できるものは自動化するという考え方を持っていない人なのですか？一般pukiwiki管理者が、たまの更新時に、どの時点でディレクトリが移動したのかなどいちいち調べるなんてやってられません。そのぐらいの想像力もありませんか？ --  &new{2007-03-05 (月) 03:00:57};
--ユーザのことも考えてほしいですね。 --  &new{2007-03-05 (月) 03:02:00};
--開発者(メンテナー)のことも考えてほしいですね。 -- [[よっちい]] &new{2007-03-05 (月) 23:02:08};
--移行して欲しいと思うなら開発グループ入って音頭とればいいのにと思うんだが・・・・聞いてると簡単に出来ると思ってる人が多いみたいだし。 --  &new{2007-03-06 (火) 18:50:38};
-- コメントありがとうございます。ただ、上でコメントされている方よりも危険な認識をされている様に思います。その文脈の&color(red){''「一般のPukiWiki管理者」に該当する方や、CVS版との付き合い方を知らない方は、CVS版を使ってはいけないのです''};。今回のような苦情は、関数やクラスを、あるファイルから別のファイルへと移動させたような時にも主張する事ができますが、そのようなストレスはcvsでなくても受けるもので、マージの際に受けるストレスとしてはごく軽いものです((マージ作業前に状況を知ることができ、それなりに構造化されたコードであれば、普通は変更点も極小化されているため))。[[CVS版]]に関する警告がまだ足りないのなら後で追加しましょう。しかしその運用体制であれば、ストレスを感じるリスクが高いのは当たり前です。そしてそのストレスは、ツールがcvsかどうかと関係がありません。リポジトリの更新状況すら事前にチェックしないと言うその((安易と言われても仕方ありません・・・))運用を見直して下さい。((過去のCVS版や、cvsに対するツッコミについては、CVS版、[[BugTrack/556]]、 [[BugTrack/659]] などがあります))((蛇足ですが、何もカスタマイズしていないファイルであれば、cvsであっても、ファイルの移動はコマンド一つで追随可能です)) -- [[henoheno]] &new{2007-03-09 (金) 00:39:07};
-- そういう話ではないですね。svn と cvs とどちらが楽かという話です。そして svn のほうが一般的な事例に対して楽だから svn への移行ををして欲しいという話です。論点をずらしてはいけないのです。 --  &new{2007-03-09 (金) 08:33:38};
--- ここで言う''一般的な事例''が伝わってないのだと思いますが。わたしはcvsとsvn両方使ってますが''わたしにとっての一般的な事例''において、それほど違いは無いと思います。むしろ特殊なところが違うというか、一長一短あるような。 -- [[よっちい]] &new{2007-03-09 (金) 13:31:57};
-- 「めんどうくさいからやりません、とりあえず」のほうがまだ説得力と人間味があってよろしい。 --  &new{2007-03-09 (金) 08:34:50};
-- '''一般pukiwiki管理者'''はCVS版を使う必要がないので関係ないでしょう。あくまで開発者向けなのですから、デバグに協力する気のない人たちの要望に応えて開発環境を移行することは無意味でしょう。svnに移行を希望する方は、まず日頃からバグ報告等フィードバックを行うとよいと思います。そういう方がsvnに移行を希望すれば、移行してもらえる可能性も高まるのでは。開発がより進む可能性が高まりますからね。 -- [[ぃぉぃぉ]] &new{2007-03-09 (金) 12:31:41};

#comment