5

私はほぼ 2 年前に新しい仕事を始めましたが、SVN リポジトリ プロセスは既に存在していました。SVN を利用してコードベースを管理するための最善の前向きな方法についてあまり考えられなかったので、そのプロセスがこのようなものになりました。今、私たちはこれ以上成長する前に変化を起こさなければならない状況にあります。私たちは、ニーズに合った SVN を使用するためのより良い方法を探しています。

  • すべてのクライアント コードがその上に置かれ、1 つのリポジトリで管理されるベース フレームワークがあります。
  • また、すべてのカスタム perl モジュールを管理するリポジトリと、ベース フレームワークのすべてのスキンを管理するリポジトリもあります。
  • 次に、顧客のビジネス ユニットごとにリポジトリがあります。

/var/www、/usr/local、/opt ディレクトリとそのサブディレクトリで重複することがある、これらすべてのリポジトリにまたがるコードがあります。

これまでは、サーバーの作業領域 ( /var/www、/opt、/usr ) で変更を行い、すべての変更とそのディレクトリ構造をホーム ディレクトリの作業コピーに移動することでこれを管理してきました。これらのファイルに対して svn 操作を実行できます。

サーバーのルートを介してリポジトリをチェックアウトする実験をいくつか行いましたが、すべての svn 操作を sudo する必要があります。もう 1 つの懸念は、repository-for-customer-a に切り替えてベース フレームワークに変更を加える必要がある場合、それらの変更は追跡されるのでしょうか? それらは、repository-for-customer-a の svn stat に含まれますか? または、SVN コミットを行うと、サーバーは一度に両方のリポジトリにファイルをコミットしますか?

私たちが行っている方法で SVN を管理することは完全に非効率的であり、修正/変更に不可欠なファイルが失われることが多く、コードをトランクにマージする際に SVN の分岐/マージするので、ゲートキーパーの仕事が増えます。私たちのプロセスには多くのオーバーヘッドがありますが、SVN を意図したとおりに活用する方法を理解できれば、ここで取り除くことができます。

私が Stack Overflow に参加したのは、ここの形式とコミュニティを大いに尊重しているからです。どんなアドバイスでも大歓迎です！

4

1 に答える 1

1

ソース コードとインストールされたプログラムを明確に区別すると、ワークフローが大幅に改善されます。次のように、コードはソースの場所 (本番環境とは無関係) からインストールされた場所に流れる必要があります。

http://your-svn-server

       | checkout
       v

/home/local-checkout

       | make install
       v

/var/www   /opt   /usr

を除いて、コードがこの階層で上に移動しないことを確認してくださいsvn commit。特に、/var/www にモンキー パッチを適用してから、チェックアウトしたディレクトリにファイルをコピーしないでください。関連するすべての変更をコピーすることはありません。

これは大変な作業のように聞こえますが、そうではありません。通常、スクリプトのmake install実行にはほとんど時間がかかりません。特にコンパイラが関与していない場合は特にそうです。利点として、定義された展開手順は、将来、別のボックスに移行したり、一般的に何かを新しいマシンにインストールしたりするときに非常に役立ちます.

于 2013-02-14T15:45:17.820 に答える