2

私のグループには3人の開発者がいて、全員が.NETVBシステムである同じプロジェクトに取り組んでいます。それらは通常異なる機能で動作しますが、同じファイルを変更するために衝突することがよくあります。ソースファイルはネットワークデバイス上で共有されます。もちろん、誰もが独自に作業コピー（WC）を持っています。質問は、SVNリポジトリを設定するための最良の解決策は何ですか？：

1）メインソースファイルをトランクディレクトリにインポートしてから、3つの異なるWCでチェックアウトします。それぞれローカルマシンの特定のユーザーに対して、その単一のリポジトリからのすべての競合/マージ/コミット/更新を処理します。ブランチ。
2）トランクディレクトリにメインソースファイルをインポートし、単一の「ブランチ」ディレクトリにコピーして、そこからすべての操作を処理します。すべてが設定されたら、トランクとブランチ間のマージを処理します。
3）トランクディレクトリにメインソースファイルをインポートしてから、次のように3つの異なる「ブランチ」ディレクトリにコピーします。

svn copy trunk-> branchs / user1; svn copy trunk-> branchs / user2; svn copy trunk-> branchs / user3

次に、すべての異なるマージを処理します。これは少し複雑だと思います。
4）他の解決策はありますか？

たくさんありがとう。

4

3 に答える 3

1

各開発者が個人的な履歴を維持できるため、私自身はオプション #3 を好みます。分岐とマージは頻繁に行うほど簡単になるため、短期的にはこれが実行可能であることがわかるかもしれません。このワークフローは、私がベスト プラクティスと考えるようになった機能分岐にもうまく対応しています。

長期的には、このチームを拡大する予定がある場合、SVN はこのワークフローにはあまり適していません。この方法で作業したい場合は、 GitやMercurialなどの DVCS を検討してください。これらは分岐とマージを大幅に簡素化します。

于 2013-03-11T13:39:36.270 に答える
0

早期分岐モデルを採用する必要があるようです。メイン ソースを にインポートしtrunk、それから分岐して、チームで作業します。通常の開発中に、ある人の変更が別の人の変更と競合する場合がありますが、それはどのバージョン管理システムでも予想されることです。積極的に学び、それを学習体験として取り入れてください。ブランチでの作業に満足したら、マージして に戻しますtrunk。

いくつかの指針：

  • trunk王です。自分が何をしているのか本当にわかっていない限り、trunk常に「ゴールデン」状態にある必要があります。つまり、ビルドを壊すようなコミットがあってはなりません。
  • ブランチに適切な名前を付けます。その週に関連するいくつかの開発タスクを選び、適切な名前でトランクから分岐し、それに取り組み、週末にマージして戻します。その後、ブランチを削除し、新しい名前で新しいトランクを作成できます。時間が経つにつれて、トランク (v1.0、v1.1 など) からのリリースにタグを付けることができます。
  • 意味のあるコミット メッセージで小さなコミットを行います。3、6、12 か月後に役立ちます。

詳細については、こちらとこちらをご覧ください。

于 2013-03-11T13:48:31.137 に答える
0

まず、「ソース ファイルはネットワーク デバイスで共有されます」とおっしゃいました。それはどういう意味ですか？一部のサイトでは、共有ネットワーク ドライブがあり、file://チェックアウトとチェックインに使用されます。あなたがそれをしているなら、それをしないでください。svnserve代わりに または Apache HTTPD を使用してください。svnserveWindows でのセットアップは非常に簡単で、Windows サービスとしてセットアップする方法についての指示がたくさんsvnserveあるため、自動的に起動して再起動します。主な問題は、ポート 3690 がネットワーク上でブロックされているかどうかです。既に統合されている Apache httpd と Subversion をインストールする Windows パッケージもいくつかあります。一部は完全にオープン ソースのソリューションですが、ほとんどは無料です。

時折のファイルの衝突は問題になりません。Subversion は非常に正気な方法で衝突を処理することができます.. 開発者Aが作業コピーをチェックアウトし、開発者Bもチェックアウトするとします。開発者AとBの両方が foo.vbs を変更します。開発者Bが最初にコピーをコミットします。開発者Aが変更をコミットしようとすると、開発者Bが作業コピーを更新して開発者Aの変更を含めるまで、Subversion は開発者Bのコミットを許可しません。開発者Aがこれを行い、変更をテストすると、変更の組み合わせセットをコミットできます。これが最初のシナリオです。

シナリオ 3 を使用して、各開発者が個別のブランチで作業することにより、実際にはシナリオ 1 と同じことを行います: 開発者AとBの両方がトランクからブランチを作成し、それぞれのブランチからチェックアウトします。マージせずに作業を自分のブランチにコミットできますが、遅かれ早かれ、コードをトランクにマージする必要があります。次に、最初の開発者は簡単にマージできますが、2 番目の開発者はマージの競合を処理する必要があるという同じ問題が発生します。

唯一の違いは、マージの衝突を処理する必要がある場合です。シナリオ #3 では、開発者はゲームの後半までマージの衝突を無視できるため、マージの処理がさらに難しくなります。シナリオ #1 では、開発者は問題がまだ小さいうちにすぐに問題を処理する必要があります。何十人もの開発者が同じブランチで問題なく作業しています。

于 2013-03-11T15:32:21.500 に答える