subversion 共有ライブラリの管理

質問

基本的なクラス群や関数群をいくつかのプロジェクトで共有する場合、
Subversionでは、それらのソースを皆さんどのようにで管理されているのでしょうか。

たとえば、以下のようにprojectAとprojectBでfolder_C以下にあるコードを共有する場合、
folder_Cを、独立したプロジェクトで管理してプロジェクトAやBから外部参照する方法でよいのでしょうか。

prjA-trunk-folder_A
|-folder_B
|-folder_C

prjB-trunk-folder_E
|-folder_F
|-folder_C

prjC-trunk-folder_C

回答No.2

Wr5 · ベストアンサー

>他のプロジェクトと共有する(している)コードを修正した場合、
>のちほど、その変更内容を他のプロジェクトのものへ反映させる
>ということでしょうか。

そういうレベルでの他のプロジェクトに流用するものではない。
というだけです。
複数のプロジェクトで共有するDLLですが、使用用途は限られているものです。(共有ライブラリの依存度などの問題…かと。)
Visual Studioでのソリューション単位でリポジトリに登録する。というつもりです。
# あくまでも私の運用の予定…です。それが正しいというコトではありませんので。
# 全く別の開発グループが参照する。とか、共有ライブラリを使用しているプロジェクト内容は見せたくない。という場合などには外部参照の方が都合がよい…かと。

以下、私の運用で…
　Visual StudioのソリューションA
　　|-共有DLLのプロジェクト
　　|-アプリAのプロジェクト
　　|-アプリBのプロジェクト
をSubversionのリポジトリに丸ごと入れます。(ソリューション/プロジェクト内でリポジトリへの登録するもの/しないものは選択しますが)
共有DLLを使用するアプリCを追加する場合…全体をブランチ切って、ソリューションにアプリCのプロジェクトを追加し、Subversionリポジトリに追加します。
アプリCの目処がついたところでtrunkに戻してマージするでしょう。
公開するとしても成果物(共有DLLと各実行ファイル)だけで、Subversionのリポジトリまで公開するつもりはありませんし。

共有DLLの方の機能拡張などでブランチ切る場合は一番上から丸ごと切ります。
共有DLLのディレクトリ(プロジェクト)下だけブランチ切ることも可能でしょうが…管理が面倒になりそうなので。
外部参照ならば共有DLLのディレクトリ(プロジェクト)だけブランチ切っても全体には影響しない…んでしょうな。おそらく…。

開発停止されたようですが…
Lhmelt、UNLHA32.DLL、UNARJ32.DLLの様な関係であれば、外部参照で管理するように作る…でしょうね。
# もっともこの場合、Lhmeltで必要なのはビルド後のバイナリだけなので外部参照にするかどうかも微妙？

お礼

早速の回答ありがとうございます。

SubeversionやWinCVSの検索をかけても、ツールの使い方はたくさんでてくるのですが、
具体的にどのようにプロジェクトを管理しているかのポリシーみたいなものは
あまりでてこないので、大変参考になります。

>そういうレベルでの他のプロジェクトに流用するものではない。

ツールの使い方うんぬんを考えるまえに、
ここをしっかり守るように意識したいと思います。

ありがとうございました。

回答No.1

Wr5

用意されている機能ですし…外部参照なんじゃないですかね。
TortoiseSVNもSubversion自体は外部参照になってますね。

コミットするときとか、どういう動作になるのか…試したコトがないのでなんとも。
# 必要性があれば…まぁ試すんでしょうけど…　自由にいぢれるSubversionサーバもあるし。

私の場合、今後いぢる予定のモノは…複数纏めて1つのリポジトリで管理する予定です。
共用するDLLと、それを利用するEXEで…。
以降の取り扱い(できたものを公開するかどうか)も合わせてセットで取り扱う予定ですし。

お礼

回答ありがとうございます。

追加の質問をさせて頂けないでしょうか。

>私の場合、今後いぢる予定のモノは…複数纏めて1つのリポジトリで管理する予定です。

他のプロジェクトと共有する(している)コードを修正した場合、
のちほど、その変更内容を他のプロジェクトのものへ反映させる
ということでしょうか。

お時間がありましたら、教えて頂けると助かります。