3

複数のプログラマーが同じコードベースで同時に集中的に作業する方法を想像できます。

  • サーバー上のバージョン管理システムは、コードベースに接続しているプログラマーの 1 人が編集を開始したときに、編集のために 1 つのファイルをロックできるはずだと思います

  • コードベースの変更に関するライブ通知と、更新されたファイルの他のユーザーへのプッシュ (通知または自動更新による)

  • その場で変更セットについてチャットし、コミットと差分を表示します (Trac のような統合されたソース履歴ブラウザーや類似のものでも問題ありません)。

  • 一部の注目の IDE (Netbeans や Eclipse など) と統合されたソリューション

しかし、これに対する安価な（オープンソースが完璧だろう）ソリューションは何ですか？
テスト済みで、使用を推奨できるシステムは?

編集番号1：
提案されたソリューションは、私が問題に書いたすべての機能を提供する必要はありません。このリストは、要件リストではなく、このシステムに何があり得るかという私の架空のリストです。質問は、「svn/cvs/etc でのマルチユーザー作業」をどのように解決するのか、そしてどの解決策が最も好きかについてです。

編集番号 2
@thiton コメントの周りRCS ( Revision Control System
) と呼ばれるものが存在することを指摘することは非常に重要です。私が知っている限りでは、RSC は CVS の祖先です。概念としての CVS は、svn、git、mercurial、bazaar などで実装されています。RSC からその後継に移行した理由は、古いやり方では速度が低下し、チームワークが過度に複雑になったためです。ファイルをロックして、編集が終わってから解放するというのは、私たちが望んでいる方法ではありません。単一のファイルの変更を元に戻す (特定のリビジョン番号に戻す) ことができるようになり、自分や他の人の障害を修復できるようになりました。その必要があります。

だから私はリストの最初のポイントを打ち消しました（優先度の降順で書き留められていないことに注意してください）、それを思い出させてくれた@thitonに感謝します.

4

4 に答える 4

1

バージョン管理システムの使用に関しては、複数の考え方があります。

私の好みは、今後の各機能を別々の機能ブランチで機能させ続けることです（どんなに小さくても）。この機能に割り当てられた人は、自分で変更を加えるだけで作業できます。他の開発者からの干渉はありません。

バグ修正（本当に些細なものは別として）も、幹線を安定してきれいに保つために、最初に別々のブランチとして実行されます。最新のトランクリビジョンは、常に製品の最後に配信されたバージョン（リリース）に対応します。

新しいリリースが準備されているときに、変更が1つだけで、その変更自体が以前に提供されたバージョンに基づいている場合、テストはブランチバージョンに対して実行でき、新しいリリースの時点で、ブランチはトランクバージョンに統合されているだけです。cvsやsvnなどのバージョン管理システムは、この種のマージ操作を適切にサポートしています（私自身はgitを使用していませんが、ブランチとマージはそこでも適切に処理されることを理解しています）。

統合するいくつかの明確な変更がある場合は、個別の「統合」ブランチを作成することを好みます。最初に、統合するすべての変更を1つずつ収集します。繰り返しになりますが、バージョン管理システムは、競合する編集（つまり、単一のコードファイルの1つの場所での2つの異なる変更）がある場合にフラグを立てます。彼らが理解できないことは、いくつかの明確な変更によって引き起こされた機能の競合があるかどうかです。したがって、統合のたびに、少なくともある程度の監視が必要になり、場合によってはテストも必要になります。

次に、個々の変更がすべて統合ブランチに統合されたら、徹底的にテストし、リリースの準備ができたらトランクに再度マージできます。さらに修正を加える必要がある場合は、元の機能ブランチでさらに修正を加えてから、修正を統合ブランチに統合することができます。

トランクには常に最新のリリースが含まれているため、この方法はバグ修正応答の高速化に非常に役立ちます。また、個別の機能ブランチは統合された場合にのみ幹線に影響を与えるため、投機的な開発にも適しています。また、リリースは機能ブランチで進行中の開発に影響を与えないため、機能は複数のリリースサイクルにわたって機能する可能性があります。このようにして、「バスファクター」（開発者の1人がバスにひかれた場合に何が起こるか）も減少します。不完全でコンパイル不可能なコードでさえ、機能ブランチでチェックインできます。そして、何らかの理由で誰かが仕事を欠いている場合、行われたすべての作業は他の開発者が利用できます。また、ワークステーションの災害は、ワークステーションがチェックインもバックアップもされていない1週間分の開発作業を簡単に保持できる場合のように、大きな心配を引き起こしません。

新しいリリースが行われるときに、長寿命の機能ブランチを常に最新のリリースに更新するかどうかは、ポリシーの問題であり、前回のリリースで何が行われたかによっても異なる場合があります。ポリシーのもう1つの問題は、統合ブランチの所有権です。すべての機能ブランチの変更を収集し、他の変更に合わせるために必要な小さな変更を行う責任があるのか​​、または各機能開発者/チームがその特定の機能ブランチから統合への変更を取得する責任があるのかブランチ。私は別の「リリースビルダー」（もちろん、通常は機能開発者の1人です）を好みます。

少なくとも私の現実では、3〜4人の開発者は、他の方法で相互に通信する場合、単一のブランチでかなりうまく機能するようです（共有オフィススペースが推奨される方法です）。彼らは自分たちで仕事を整理し、お互いのつま先を踏まないようにすることができます。また、個別の機能ブランチが互いに同じファイルに触れることはめったにないように思われるため、ほとんどのマージサイクルはかなり苦痛がありません（苦痛なものは変更の説明から予測できます）。一方、変更がブランチに分離されていない場合、複数の別個の同時変更タスクを複数のタスクで実行する単一の開発者でさえ、問題が発生することになります。

したがって、要約すると、ファイルをロックするのではなく、優れたバージョン管理システムを使用し、ブランチを勇敢に活用し、ブランチからの変更をマージするときに目を離さないでください。

于 2011-12-30T21:11:01.880 に答える
1

他の人が変更をコミットしたときに作業ツリーのライブ更新が本当に必要な場合は、ClearCase のようなものが必要ですが、それは明らかに安くはありません (そして、私と私が知っているほとんどの人はそれを嫌っています)。

それ以外の場合、準備が整ったときに他の人の変更を手動でプルしたい場合は、編集 2 でリストしたすべての VCS が電子メール通知を行い (ほとんどの場合、フック スクリプトを自分で作成する必要があります)、ほとんどの場合、グラフィカルな機能があります。差分などを行うインターフェース。

どちらを推奨するかを決定するのに十分な情報が提供されていません。集中化するか分散化するかを決定する必要があり、それ以上は好みの問題です。チャット機能が統合されていることは知りませんが、IRC サーバーをセットアップしたり、freenode でルームを作成したりするのは難しくありません (機密事項を何もしていない場合)。

SVN、Git、および Bazaar はすべて適切なオプションです。私は Mercurial を使ったことはありませんが、良い評判を聞いています。Arch は動作しますが、私は好きではありません。CVS は機能しますが、変更セットを使用すると、後で履歴が (はるかに) 理解しやすくなります。

他の VCS も利用できます。

于 2011-12-30T19:44:27.007 に答える
1

あなたの質問は、アプリケーション ライフサイクル管理 (ALM) と多くの ALM ツールキットでカバーされています。そのようなツールキットの例:

  1. アトラシアン製品: Jira (課題追跡)、Fisheye (差分ビューアー/リポジトリ ビューアー)、Crucible (コード レビュー ツール)、その他 (Confluence、Bamboo、Clover)。これは、あなたが説明した問題に直面している人にお勧めする一連の手段です。Jiraがおそらく最も人気のある課題追跡システムである限り、Jiraの機能については説明しないほうがよいと思います。Subversion-Jira プラグインを使用して、課題追跡とバージョン管理を統合することができます. このプラグインをインストールして構成すると、コミット コメントで課題番号 (#234、#687 など) を指定できます。このコミットが課題に貢献しているため、Jira は特定の課題の下にあるすべてのコミットを表示します。これらのコミットの内容を表示するには、 Fisheyeが必要です。表示するだけでなく、変更にコメントを付けたり、変更セットをリンクの形式で配置したりすることもできます。FishEye があれば、changeset や commit の参照に問題はありません。コラボレーションのもう 1 つのレベルはCrucibleです. バージョン管理システムで他のユーザーが実行したすべてのコミットのコード レビューを実行できます。非常に柔軟です。たとえば、特定のコミットの特定のソース コード行の前にコメントを入れ、その場でサブタスクを作成し、独自のコードをレビュー コメントに入れることができます。アトラシアンのツールは、お金で買える最高のツールです。ご覧のとおり、無料ではありません。そしてそれがあなたがそれを好きではないかもしれない理由です。ただし、代替手段はあります。
  2. ViewVC -リポジトリ ブラウジング/差分ビューアーツール。フィッシュアイの代替と見なすことができます。
  3. WebSVN - 別のリポジトリ ブラウジング/差分ビューアーツール。
  4. モニターをコミットします。常に電子メールで通知されるとは限りません。この場合、コミット モニター(Windows で実行) が役立つ場合があります。誰かがコミットすると、デスクトップにポップアップが表示されます。個人的にはメールより便利です。さらに、コミット モニターで直接、最後のコミットのリストを表示できます。Windows で実行する可能性がない場合は、 WineまたはSubversion Commit Monitorを使用してください。
  5. 変更リストを使用します。Subversion とTortoiseSVN の両方にチェンジリスト機能があり (チェンジセットとは異なります)、便利なことがよくあります。これについて知っておく必要があるのは、変更リストは問題の概念に似ていますが、バージョン管理レベルにあるということだけです。

上記のすべてのツールに加えて、Subversion リポジトリには次のリポジトリ構造を使用することをお勧めします。

    /project
        /trunk
        /tags
            /builds
                /PA
                /A
                /B
            /releases
                /AR
                /BR
                /RC
                /ST
        /branches
            /experimental
            /maintenance
                /versions
                /platforms
            /releases

このリポジトリ構造は、バージョン管理の次の重要な側面に焦点を当てています。

  1. ブランチを使用する
  2. ブランチが必要な理由を常に把握する
  3. タグを使用する
  4. タグが必要な理由を常に知っておいてください:)
  5. svn:externals を使用します。これは、アプリのモジュール化を試み、モジュール間の依存関係を考慮する必要があることを意味します。
  6. 「プロジェクトごとのリポジトリ」アプローチを使用します。アプリをモジュール化し、頻繁な間違いを避けるのに役立ちます。
  7. 継続的インテグレーションを使用します。リポジトリにあるブランチの現在の状態を追跡するのに役立ちます。実際、継続的インテグレーションは、共同作業やチームのコミュニケーションに大きな影響を与えると考えられます。以前に継続的インテグレーションを使用したことがなく、どこから始めればよいかわからない場合は、CruiseControl (CruiseControl.NET および CruiseControl.rb も)、Hudson、Jenkins、Bamboo、TeamCity、Continuum など、多くの選択肢があります。

このような規則が存在する場合に非常に役立つため、このリポジトリ構造について言及しました。

  1. コミュニケーション。何をしているかを説明するために、コミット ログに多くを書き込む必要はありません。対応するアーティファクトを VCS に追加するだけです。
  2. 間違った動きをする可能性が低くなります。多くの場合、開発者は緊急に何かを行う必要がありますが、これを行う方法を正確に知りません。それは間違った動きをしやすい場合です. そのような一般的な動き (VCS に関して) のリストが wiki のどこか (見つけようとする場所) ではなく、すぐにリポジトリに存在する場合、非常に役立ちます。
  3. 質問が少ない。ほとんどの場合、リポジトリにそのような構造を持つことは自明です。VCS で何かを行う方法についての質問が少ないほど良いです。
于 2011-12-31T12:00:24.087 に答える
1

Subversion (svn) でやりたいことができます。ライブ通知で私が気に入っているのは、変更の差分を含むすべてのコミットの後に送信されるメールです。これは最初は奇妙に思えますが、慣れるとすぐに、利用できないと恋しくなります。

すべての開発者は電子メールを持っており、その処理方法を知っています。邪魔されたくない場合は、メール クライアントを閉じてください。サーバー上で実行されるため、すべてのツールで動作します。この質問に関するチュートリアルを見つけることができます。

1 人の開発者がファイルを編集している場合、ファイルをロックしません。この場合、他のすべての開発者は変更を加えることができず、全員が遅くなります。ビジネス ロジックのヘルパー クラスが長い場合、これは静かに高速に発生します。

また、作業コピーを自動的に更新しません。プロジェクトをビルドしている場合やファイルを変更している場合、競合が発生しやすくなります。最良の場合は、再度ビルドするだけで済みますが、最悪の場合、最後のコミット以降のすべてのデータが失われます。

分散バージョン管理システムを好む場合は、フック スクリプト アプローチを git および mercurial でも実行できます。その場合、フックは、マスターとして選択したリポジトリで実行されます。

于 2011-12-30T18:07:16.673 に答える