1

2 組の開発者と相反する要件を管理しようとしています。1 つのグループは、プロジェクトに複数のファイルがある Java アプリケーションを実行しており、別のセットは、Oracle フォーム、レポートなどの単一ファイルで動作します。両方のセットは現在 vss にあり、Java の担当者は git を試しましたが、oracle/vss の担当者はそれを嫌っていました - 主にロックの欠如. 妥協案として、svn を試して svn:needs-lock を実装しました。しかし、次の問題は、ラベル/タグの同等性を販売することでした。たとえば、SourceSafe のような Subversion の「ラベル」です。

しかし、私の知る限り、少なくともこの構造がなければタグを付けることはできません:

  • mystandalonefileproject/trunk/mystandalonefile
  • mystandalonefileproject/tags

開発者は、大きなオラクル フォーム ディレクトリで自分のファイルを見て、それを直接取得、チェックイン、ラベル付けしていましたが、これは苦痛の原因でした。

これに対処する方法について何か提案はありますか? 上記の構造を任意のファイルにセットアップするための小さなスクリプトを開発しましたが、vss から svn への移行中に作成することについて考えました。

他のアイデアはありますか？そして残念なことに、SubversionとVSS によって管理上の問題が発生します。

4

1 に答える 1

1

タグ/ブランチ/トランク構造でSVNを実行する必要はありません。ユーザーが古いVSSスタイルのレイアウトに満足していて、ワークフローがうまく機能している場合、他のレイアウトに移行する本当の理由はありません。

SVNはVSSに近いスタイルで実行できるので、まずはそれを実行します。'needs lock' autopropを有効にして、緩めます。次に、Tortoiseとスパースディレクトリチェックアウトに慣れたら（一般的なVSS操作をSVNと比較する方法を説明するドキュメントにします）、リリースされたコードを新しいブランチに分岐するなど、ワークフローの改善を提案し始めることができます。 、たまたま「タグ」と呼ばれるディレクトリに配置すると、「ブランチ」と呼ばれる別のディレクトリでいくつかの作業が実行されることを提案できます。次に、マージと、他の誰かがマイナーな変更をチェックアウトしたコードを操作する必要がないことの利点について説明します。

人々は変化を好まない、それは公平なので、徐々にそれを紹介するだけです。SVNに変更し、それらの動作方法を変更することは良くありません。2つの簡単なステップでそれを行うと、成功する可能性がはるかに高くなります。

于 2012-05-08T14:22:20.997 に答える