1

私はこれに関するスタックオーバーフローに関する他のいくつかの質問/回答を読みましたが、可能であればいくつかの説明を得たいと思いました。

状況-約20個のdtsxファイルがあり、これらのパッケージへの変更を追跡するためにSVNの使用を開始したい-許容可能なdtsxファイルを含む複雑なXMLのため、SVNを使用するとパッケージ内の変更をマージできない可能性があることを認識していますSVNは、変更の追跡において引き続きいくつかの利点を提供します。現在、開発/展開戦略では、各開発者が必要に応じてターゲットサーバーからdtsxファイルをロードし、ローカルで開発してから、ファイルをターゲットサーバーにコピーして戻します。各開発者は、すべてのパッケージが含まれている大規模なプロジェクトを作成するか、dtsxの変更が必要になるたびに新しいプロジェクトを作成するかなど、独自の戦略を使用します。

この環境でSVNを実装するための効率的な方法に関する提案を探しています-VSプロジェクトファイル（たとえば）をSVNコントロールに含める必要がありますか？そうでない場合、開発者はどのようにして「Subversionからプロジェクトを開く」のですか？すべてをVS内で実行できますか、それともWindowsエクスプローラーに移動し、フォルダーレベルで更新してから、VS内から既存のパッケージを追加する必要がありますか？そのようにすると、VSからコミットできますか？

このようにSVNを使用するのは初めてで、特定の手順を期待している基本的な質問については申し訳ありません。

4

1 に答える 1

2

質問のタイトルに「AnkhSVN」が含まれているので、それを使用していると思います。

もしそうなら、はい、私はあなたのVSプロジェクトファイルをSubVersionに含め、それらをBIDS/SSDTでSVNにバインドすることを強くお勧めします。そうすれば、ローカルではなく「ソース管理からプロジェクトを開く」ことができ、プロジェクトレベルで再帰的なチェックインを行うこともできます。

また、「アプリケーションごとに1つのプロジェクト」ルールを作成して、プロジェクトの作成を標準化することを強くお勧めします。人々にパッケージ変更のための彼ら自身の1回限りのプロジェクトをただカウボーイにさせることは、私見、愚かで非生産的です。

私たちにとって最大の課題は、SSISのような「差分なし」の環境でプロジェクトにパッケージを追加することだと思います。SSISパッケージでデータフローを開くたびに、ファイルがチェックアウトおよび変更され、プロジェクトファイルも変更されます。人々は通常、これらの「変更なし」の変更を盲目的にチェックインします。したがって、次のようなシナリオが得られます。

  1. アリスはプロジェクトにパッケージを追加し、チェックインします。
  2. 一方、Bobは、ソースクエリをチェックするためだけにパッケージのデータフロータスクを開き、プロジェクトファイルをチェックアウトします。
  3. 彼は自分の変更をチェックインします。それは彼にアリスのチェックインとの競合を与えます。彼はただローカルを使用することを選択します。
  4. 現在、アリスのパッケージは無人地帯にあり、チェックインされていますが、プロジェクトには含まれていません。その展開に気をつけてください...

とにかく、いくつかのガイドラインと議論でこれを明らかに軽減することができます。また、SVNのある種の事実上の「ゲートキーパー」を用意することをお勧めします。これは、乱雑になり、とにかくソース管理の定期的なクリーンアップが必要になるためです。

たった20個のパッケージで、断続的なパッケージ変更だけのように聞こえますが、おそらく分岐は必要ありませんが、少なくともそれについては読んでおく必要があります。分岐は、チームがお互いのつま先をたくさん踏み始めたときに成長するものだと思います。分岐は、いつ制定するかという判断の呼びかけのようなものですが、開発者が慣れている場合は、それを使用することをお勧めします。

于 2012-12-06T15:20:13.167 に答える