現在、テストサーバーにオープンソースプロジェクトをインストールして構成しています。私はソース管理を使用するように十分に訓練されており、私が行うすべてが適切に管理されていることを確認したいと思います（私、唯一の開発者/管理者、および将来の保守担当者の両方）。オープンソースプロジェクトは、ソースのダウンロードまたはsvncheckoutから入手できます。
プロジェクトの独自のソース制御バージョンが必要です。（javaサーブレット）コードを（仮にあったとしても）あまり変更するつもりはありませんが、構成、XMLファイル、XSL、CSSなど、すべてソース制御したいものがあります。
先に進んで、すべてのソースコードの独自のローカルリポジトリを作成する必要がありますか？変更する必要のあるファイルのみを制御する必要がありますか？その場合、ディレクトリ構造を一致させたいので、ビルドディレクトリに直接チェックアウトできます。
サードパーティ プロジェクトのサイズとカスタマイズの量に応じて、いくつかの方法を使用しました。
小規模または高度にカスタマイズされたプロジェクトの場合は、ストック コードから始めてすべてをチェックインします。これにより、プロジェクト全体の作業が容易になり、ビルドに必要なすべてをチェックするための「ワンストップ ショッピング」が提供されます。
大規模なプロジェクトやわずかにカスタマイズされたプロジェクトの場合は、ストック アーカイブ (通常は.tar.bz2または.zipファイル) のコピーを保持し、確実にバックアップします。次に、カスタマイズを具体化するファイルを何らかの形でリビジョン管理下に置きます。ここでのオプションは
カスタマイズされたファイル自体を (のみ) チェックインします。ソース コードを変更する場合は、通常、これが最適な選択です。
カスタマイズを行うスクリプトをチェックインします。これは、スクリプトが構成ユーティリティに入力を提供する場合に最も効果的です。これは、カスタマイズ (入力データ) をストック部分 (構成ユーティリティ) とは別に保存しているためです。サードパーティ ライブラリの新しいバージョンがリリースされた場合、通常はカスタマイズを簡単に適用できるため、重要なアップグレードが可能になります。
「絶対に変わらない™」プロジェクト、または顧客が契約上特定のバージョンに拘束しているプロジェクトの場合は、ストック コードをどこかに保存し、リビジョン管理下でパッチ ファイルを作成します。その後、パッチを適用して「承認済み」バージョンをリリースできます。 注: パッチ ファイルは維持するのが面倒なので、これは非常に恐ろしい選択です。新しいパッチを作成する場合は、パッチ ファイルを再作成するか、最初のパッチの上に適用される追加のパッチを作成する必要があります。このオプションを選択する理由は、通常、技術的な理由では選択されません。
この種のプロジェクトを構築してカスタマイズを追加するプロセス全体を文書化するか、自動化するか、または (できれば) その両方を行う必要があることはいくら強調してもしすぎることはありません。 どのファイルがどこに、または誰のものであるかを驚くほど簡単に忘れてしまい、最初からやり直すのは苦痛です。相続人なら特に。
幸運を！
同じディレクトリ ツリーへの 2 つのチェックアウトは機能しません。ソースをチェックアウトし、OSS プロジェクトのソースをチェックアウトしようとすると、共通のディレクトリはすべて別のプロジェクトの作業ディレクトリであると言って失敗します。
css、xml、xsl などを共通のディレクトリに集めることができる場合は、それらを自分のプロジェクトの svn 内の単一のディレクトリに配置してから、OSS プロジェクトの作業ディレクトリ内のディレクトリにチェックアウトできます。
〜/作業中 => svn://samhoice/project/trunk
~/Working/osscomponent => svn://osshost/project/latesttag
~/working/osscomponent/config => svn://samhoice/project/trunk/config
この構造では、osscomponent ディレクトリは samhoice の svn リポジトリに存在しません。これは、セットアップ スクリプトによって OSS プロジェクトの作業ディレクトリ ルートとして追加されます。config ディレクトリは OSS プロジェクトからチェックアウトされておらず、存在しません。config ディレクトリはセットアップ スクリプトによって作成され、config ディレクトリはプロジェクト リポジトリからそこにチェックアウトされます。
したがって、このディレクトリ構造には 3 つのチェックアウトがあります。再帰的なオーバーラップがないため、サブディレクトリの svn マッピング間で競合が発生しません。
構成ファイルを OSS プロジェクトの構造内に配置する必要がある場合は、メイクファイルまたは構成スクリプトにいくつかのシンボリック リンクを追加します。おそらく、svn クライアントのチェックアウト後のフックでこれを行うこともできます。
私のプロジェクトの 1 つで、2 つのプロジェクト ツリー間でコードを共有するために、このような構造を使用しています。共有されたものは、構成セクションで推奨したようにサブツリーにあります。
私はすべてのコードをチェックインします。なぜなら、あなたがそれらを変更したくない、または今は変更する理由がわからない場合でも、他の誰かが後で理由を確認する可能性があるからです。また、バグ、または保守性やパフォーマンスを向上させるための簡単なリファクタリングなどがあるかもしれません.
SVN の基本的なレイアウトは次のようになります。
branches/
tags/
trunk/
また、一般的なディレクトリ レイアウト (これら 3 つの下) は、もちろんアプリケーションと一致している必要があるため、すぐにチェックアウトして実行できます。ただし、ビルド ファイルなどを使用してわずかな変更を行うこともできます。詳細、またはベスト プラクティスの指針については、あなたの技術を使用している他のオープンソース プロジェクトを調べます。
構成ファイルについては、チェックインしません。ただし、ほとんどのプロジェクトfoo-distでは、ユーザーにすべての構成オプションを示すファイルをチェックインします。少なくとも、既定の構成を有効にするには、にコピーfoo-distする必要があります。foo
また、バージョン管理を含むプロジェクト ホスティング用のGoogle Code、Sourceforge、またはgithubを調べましたか? 3 つすべてが無料で大量の機能を提供します。また、プロジェクトのホスティングなどのためにサーバーを管理する必要がないという点でも無料です。