2

私はコンピュータ サイエンスの研究室ではなく、エンジニアリングの研究室で働いています。そのため、当社の社内ソフトウェアは成果物ではありません。代わりに、社内のソフトウェアを使用してエンジニアリングの問題を分析し、結果を提供します。

これにより、バージョン管理が生き地獄になります。あるいは、標準的な「幹と枝」のバージョン管理ツリー構造が適用されないように見えるとだけ言っておくべきかもしれません。誰かが物事を行うためのより良い方法を提案できることを願っています。

たとえば、エンジニアリング プロジェクトごとに、ケース固有の入力ファイル、ランタイム ファイル、後処理ファイルを追加する必要があります。これらは一般的ではないため、実際にはトランクに属しませんが、新しいプロジェクトごとにこれらのファイルが必要です。テンプレートをトランクに配置しようとしましたが、テンプレートをいつマージする必要があるかについて明確なベスト プラクティスがありませんでした。

同様に、新しい機能を追加するにつれて、社内コードは常に進化しています。これらの多くは、将来のアプリケーションで使用できるようにトランクにマージする必要があります。ただし、トランクが見る必要のないケース固有のハックもかなりあります。

この混乱をどのように整理すればよいでしょうか。明らかに、シンプルなほど良いです。

4

2 に答える 2

1

私たちは、プロジェクトを別々に保つように努めています。

  • ソースファイル (SVN など、任意の VCS で管理)
  • 構成ファイル (チームまたは環境に固有)

ブランチは開発作業用であり、これらの「入力ファイル、実行時ファイル、および後処理ファイル」は独自のペースで進化します。

その種のファイルの場合、VCS で管理するものは次のとおりです。

  • テンプレート
  • スクリプトはそのテンプレートを取得し、適切な値を含む (バージョン管理されていないプライベート) 構成ファイルを生成できます。
    値は、チーム (または環境管理者) がチェックアウト/チェックイン/マージを気にせずに自由に更新できる、データベースなどの別の参照から取得されます。
    そのデータベースは、必要に応じて独自の VCS でバージョン管理できます (たとえば、このSO の質問を参照するか、代わりにその質問を参照してください) 。
于 2010-11-04T10:04:59.510 に答える
0

エンジニアリングでは、バージョン管理が過小評価されることがよくありますが、実験を繰り返すには、特定の設定を復元することが不可欠です。使いやすく、主にGUI指向の一般的な採用には、ツールが大いに役立ちます。

問題をコードコミットに関連付ける問題追跡でバージョン管理を活用すると、生産性が大幅に向上します。

リポジトリの構造に関しては、少なくともSubversionを見ると、慣例だけがありますが、ツールによって課される厳密なルールはありません。すべての「共通コード」が管理される「トランク」と呼ばれるツリーがあるのはどうですか。

すべてのエンジニアリングタスクに対して、ブランチが作成されます。これは、バージョン管理を備えた「プロジェクトフォルダ」に他なりません。他のプロジェクトに関連するソースコードは、トランクにマージされます。

于 2010-11-04T21:41:34.000 に答える