参考サイト 読んでおくといい
http://attosoft.info/jtdan/vcs/svn/svn-book/svn.branchmerge.maint.html
http://attosoft.info/jtdan/vcs/svn/svn-book/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout

------
◆2025/04/03 ソースとブランチ管理
------
Javaで開発したWebアプリケーションのサーバ更新に備えて、
現サーバ上でのバグ修正保守と、新サーバに対応するための改修を並行して行う予定です。
サーバ更新まではまだ半年以上あります。現在のソースプログラムはSubversionで管理しています。
バグ修正保守の頻度はひと月に1回程度です。
バグ修正保守と新サーバ対応改修の開発者は共通で、ソースのアクセス権も完全に分ける必要はありません。
この時、ソースプログラムの管理ミスによる品質低下を防止しつつ、効率的に開発管理を行うためには、
Subversion上でブランチを作る方法と、IDE上でソースを複製して開発ソースを分離する方法ではどちらが適していますか。
------
ブランチ管理がお勧め
・変更履歴の分離と追跡が容易
・マージの全半自動化
・最終的にブランチを統合すると履歴の一元化が可能
・様々な手作業、目視の人為ミスを抑制
------
ソースツリーをtrunk上に作っていない場合、作業コピー上でまずtrunkサブディレクトリを作り、
ソースツリーをtrunk内に移動させてから、new_serverブランチを分離すべきですか。
------
はい。ただし直下に既にファイルを置いている場合、どうtrunkに入れるかは考える必要がある。
------
Servlet/JSP仕様に基づくWebアプリケーションapp1とapp2のソースをSubversionで管理します。
2つで1つのシステムAの開発プロジェクトを形成し、開発者は共通です。保守頻度は両方とも月1回程度です。
Subversionリポジトリ上のディレクトリ構造は、以下のどちらが適切ですか？

案1:
SVN/app1/trunk/src/main
SVN/app1/trunk/src/resources
SVN/app1/branches/feature-1/src/main
SVN/app1/branches/feature-1trunk/src/resources
...
SVN/app2/trunk/src/main
SVN/app2/trunk/src/resources
SVN/app2/branches/feature-1/src/main
SVN/app2/branches/feature-1trunk/src/resources
...

案2:
SVN/trunk/app1/src/main
SVN/trunk/app1/src/resources
SVN/branches/feature-1/app1/src/main
SVN/branches/feature-1/app1/src/resources
...
SVN/trunk/app2/src/main
SVN/trunk/app2/src/resources
SVN/branches/feature-1/app2/src/main
SVN/branches/feature-1/app2/src/resources
...
------
案2が望ましい。
------
案2の方が適切だと考えます。その理由は以下の通りです：

機能開発の一貫性: 案2では、feature-1などの機能ブランチがapp1とapp2の両方を含んでいます。
両アプリが密接に連携する場合、一つの機能変更が両方のアプリに影響することが多いでしょう。
案2では、関連する変更を一つのブランチで管理できます。

同時リリース管理: 2つのアプリが同一システムの一部として同時にリリースされることが多い場合、
案2ではシステム全体の特定バージョンを容易に把握できます。

システム視点の構造: 案2はシステムA全体を中心に構造化されており、
各アプリケーションはその構成要素として位置づけられています。

共通リソースの管理: 将来的に両アプリ間で共有するコードやリソースが発生した場合、案2では共通部分の追加が容易です。

タグ付けの簡素化: システム全体のバージョンにタグ付けする場合、案2では一度のタグ付けで両アプリを含めることができます。

案1が適している場合もあります：

両アプリの開発サイクルが完全に独立している場合
各アプリを個別にリリースすることが多い場合
アプリ間の依存関係が少ない場合

しかし、「2つで1つのシステム」「開発者は共通」という条件を考慮すると、
案2の方がチームの作業効率と全体的な一貫性を高めると考えられます。
------
/SVN/
  ├── trunk/
  │   ├── app1/
  │   │   ├── src/main/
  │   │   ├── src/resources/
  │   ├── app2/
  │   │   ├── src/main/
  │   │   ├── src/resources/
  │
  ├── branches/
  │   ├── feature-1/
  │   │   ├── app1/
  │   │   │   ├── src/main/
  │   │   │   ├── src/resources/
  │   │   ├── app2/
  │   │       ├── src/main/
  │   │       ├── src/resources/
  │
  ├── tags/
  │   ├── release-1.0/
  │   │   ├── app1/
  │   │   ├── app2/

------
新サーバ移行までの間、あまりに長くブランチを持ち続けていると、
その間の別の保守改修の管理の悪化の原因になりますか。
------
はい。
・保守改修⇒新サーバ対応ブランチに定期的にマージする
・保守改修はtrunkで行う
・ブランチの管理者を明確化する
------
半年以上の長期間ブランチを保持し続ける場合、
Subversionでソースツリーのブランチを作ることは、
リポジトリ上で単にソースツリーの複製を新サーバ対応改修用に作ることと、
開発作業者の管理の観点だけで見れば大差ありませんか。つまり、
「マージが自動や半自動でできる」「リポジトリ上のディスク消費が最小限になる」
の二つ以外に、ブランチ管理の利点がありますか。
------
はい。
・ブランチ別に変更履歴を保存できる
・心理的に作業が切り分けられ人為ミス混入を防げる（どっちだっけ？という混乱がなくなる）
・複数開発者で異なるサブディレクトリ階層で複製してしまうなどの混乱が防げる
(app1はAさんがsrcから複製、app2はBさんがmainから複製…みたいなことがなくなる)
------
OracleのストアドプロシージャのPL/SQLソースファイルの管理について教えてください。
ストアドプロシージャの場合は、
・Oracle Database内部で最新ソースが常に一意に識別できる
・DBA_SOURCE等のデータディクショナリを使用して最新ソース更新日も取得できる
点がJavaやC#のプログラムと異なります。

1つのシステムを、JavaのWebアプリケーションとPL/SQLのストアドプロシージャで構成している時、
trunkやbranchesは複数の言語のソースファイルを一元管理すべきですか。
それとも「システム、言語」別に管理すべきですか。
------
システム全体で複数言語ソースの一元管理が推奨。
------
/SVN/systemA/
├── trunk/
│   ├── java/              ← Javaのソース（src, webappなど）
│   └── plsql/             ← ストアドプロシージャなどのSQLファイル
│       ├── procedures/
│       ├── packages/
│       └── triggers/
├── branches/
│   └── feature-x/
│       ├── java/
│       └── plsql/
└── tags/
    └── release-1.0/
        ├── java/
        └── plsql/

------
総じて、ブランチ管理をすることは
・ソース変更管理全体の見通しをよくする
・目視、手作業の人為的な混乱を軽減し、ミスの混入を抑制する
という、心理的、経験則的な側面が大きいようだ。
------
リポジトリ上でブランチを破棄（削除）する方法は、
リポジトリ上でtrunk内の特定のサブディレクトリを削除する操作と同じですか？
それとも何か別の方法が必要ですか。
------
全く同じ。
なお余談として、ブランチを削除しても過去の版には残り続ける(復元可能)な点も同じ。
------