プロジェクト内の投稿されたモジュールをソース管理する必要がありますか？

開発中はsites/、すべてをコードリポジトリ（SVNなど）にソース管理する必要があると言われました。

私が使用するcontribモジュール（ctools、viewsなど）には一切触れないが、自分のテーマのみを作成することを想定していますが、それでも実行できますか？

それとも、すべてをソース管理する必要がありsites/all/themes/ますか？

ありがとう

私のチームでは、現在のプロジェクトに固有のもののみを調達するように移行しました。たとえばビューを使用している場合は、drush make -fileに適切なエントリを追加し、そのバージョンを変更しますが、モジュール自体は追加しません。

これにより、現在のサイト、現在のテーマ、および機能のエクスポートに固有のカスタムモジュールで構成される非常に小さなリポジトリが残ります。

drushとdrush makeを絶対に使用できない場合を除いて、他の場所で適切にバージョン管理されているコードをバージョン管理する必要がある理由はわかりません。また、モジュールの1つをハックする場合は、独自のリポジトリのコードをバージョン管理するのではなく、サブモジュールとして追加する必要があります。（これはSVNではベンダーブランチと呼ばれていると思います）。

編集：詳細とより高度な設定については、次のリポジトリを参照してください：git@github.com：letharion / Drupal-build-scripts.gitスクリプトは、建物を含む私のチームのワークフローをサポートするためにbashで記述されています基本インストールプロファイル（NodeStream）、次にその上にあるサイト固有のプロファイル、各プロファイルのmakeファイル、パッチを適用するためのフック、または個々のビルドステップで他の変更を行うためなど。 -近い将来、それをDrush拡張機能として作成します。

@Letharionの回答の対抗策として、すべてをSVNに配置することは、一部の組織にとっては理にかなっており、実際にロールアウトを行う方法に依存しています。コントリビューションモジュールとテーマをSVNに置くことは、「過去にさかのぼって」古いバージョンのサイトを見る必要がある場合に意味があります。

これの1つの例は、contribモジュールのバグが疑われる場合、または異なる動作が見られる場合に便利です。過去のフルバージョンを復元できると役立ちます。

また、クライアントがサイトに対して行った処理を把握する必要がある場合、SVNで完全なサイトスナップショットを作成すると便利です。私は彼らのバージョンの完全なスナップショットを取り、それをブランチとしてSVNに貼り付けて比較することができます。