2

最近、Subversion からバザーのような DVCS に切り替えることについて職場で議論しました。他の人の意見を聞きたいと思います。

私はそうすることへの抵抗を単純な類似点に結晶化することに成功しました。

バージョン管理は、よくも悪くも使用できます。

バージョン管理の「ライトサイド」は、変更を追跡するために使用する場合、何かを壊したときに古いバージョンに戻ることができる場合、および変更を公開して同僚が進行中の作業を見ることができる場合です。 .

バージョン管理の「暗い面」は、それを適切に使用せず、定期的にコミットして作業を「チェックポイント」せず、ローカル チェックアウトに多数の変更を保存し、変更を共有しない場合です。あなたがそれらを作るように他の人と。

転覆は、ライトサイドとダークサイドの両方を比較的難しくします。すべての基本は機能しますが、マージはまったく簡単ではないため、(タグ付けとリリースを超えて) Subversion でブランチを実際に使用する人はほとんどいません。Subversion 自体でのサポートはひどいもので、svnmerge のようなスクリプトで改善されていますが、それでもあまり良くありません。そのため、最近では、優れた分岐とマージのサポートが共同開発に必要であるとますます考えられているため、Subversion は一致しません。

一方で、「ダークサイド」を追うのもかなり大変です。ときどきローカルの変更をオンライン リポジトリにコミットせず、行ったことを覚えていない簡単な編集でコードを壊してしまうことで、一度噛まれるだけで済みます。そのため、定期的にコミットすることになり、人々はあなたが行っている作業を見ることができます。

したがって、最終的に Subversion は、ベスト プラクティスを実装するのは少し面倒ですが、物事を大きく間違えることを難しくする、中道の優れた VCS になります。

対照的に、DVCS を使用すると、完全にライト サイドまたはダーク サイドに移行するコストが大幅に低くなります。これらの最新の VCS システムを使用すると、分岐とマージがはるかに簡単になります。しかし、分散された側面により、自分のマシン上の一連のローカル ブランチで作業することが容易になり、作業のチェックポイントを設定するために必要な詳細なコミットが提供されます。おそらく変更を公開することなく、他の人が確認、レビュー、共同作業できるようにする必要があります。変更をローカル ブランチに保持し、公開しないという摩擦は、一般に、公開されているサーバー上のブランチで公開するよりも少なくなります。

簡単に言うと、ここで質問があります。職場の開発者に DVCS を提供した場合、彼らがそれを使用して「ライト サイド」に行き、変更を中央の場所で定期的に公開し、理解してもらうにはどうすればよいでしょうか。まだ共有したくない彼らの 1 週間のローカル ハックは、最初の機能が休暇中に他の開発者が機能を完成させるために使用できるものかもしれませんか?

DVCS のライト サイドとダーク サイドの両方に簡単にアクセスできる場合、どうすればそれらをダーク サイドから遠ざけることができますか?

4

4 に答える 4

3

チームに「1 週間のローカル ハック」を共有したくない開発者がいる場合、それが問題であり、使用しているソース管理ツールではありません。あなたが説明している「ダークサイド」のより良い用語は、チームのコーディングの「間違った方法」です。ソース管理は、共同作業を容易にするために使用されるツールです。作業を共有することが目標であるという事実をチームが明確に認識していない場合、ソース管理を使用する最善の理由は適用できません。

また、分散ソース管理について少し混乱していると思います。中央の場所への公開はありません。いくつかのブランチは他のブランチよりも重要であり、多くのブランチが存在します。それを念頭に置くと、分散ソース管理は、人気のあるオープン ソース プロジェクトに最も適していると思います。私は、一元化されたソース管理は、企業やその他の明確に定義されたエンティティでの開発にはまだ優れていると認識しています。

于 2008-08-25T23:48:56.883 に答える
2

ニック、

問題が「作業を共有していない」ことであることに同意しますが、主な議論は、ツールが特定のワークフローを促進し、すべてのツールがすべての問題に等しく摩擦で適用されるわけではないということです。私の懸念は、DVCS を使用すると、SVN で取得した作業を共有しないという欠点がないため、作業を共有しない方が簡単になることです。共有しないことの摩擦が、共有しないことの摩擦 (DVCS の場合) よりも低い場合、開発者は、他の条件がすべて同じであれば、摩擦が最も少ないパスを簡単に選択する可能性があります。

分散ソース管理について混乱しているとは思いません。デフォルトでは「中央の場所」がないことを知っています。しかし、DVCS を使用するほとんどのプロジェクトには、リリース元の「中心的な場所」にある「マスター」ブランチの概念がまだあります。ただし、私の質問の目的のために、「プライベート」(開発者のみがアクセス可能) と「パブリック」(他のすべての開発者がアクセス可能) ブランチを区別するだけです。

于 2008-08-25T23:58:28.610 に答える
1

'private'ブランチと'public'ブランチを区別しますが、これらの場合の唯一の実際の違いは、ブランチのリポジトリがローカルでのみ利用可能か、会社全体で利用可能かということです。中央リポジトリは、全社的な可用性を実現する唯一の方法です。

代わりに、すべてのリポジトリが会社全体で公開されている必要があると言ってはどうでしょうか。たとえば、すべての開発者に独自のローカルVCSサーバーを実行させ、zeroconfを介してブランチを共有することができます。

于 2008-08-26T09:48:55.850 に答える
0

最新のリリースでは、svn のマージがいくらか見直されていると思います。

于 2008-08-25T23:49:44.917 に答える