5

私たちは、かなり大規模な統合プロジェクトに取り組んでいる 5 人の開発者からなる分散型チームです。私たちは現在、SourceSafe を使用しています (はい、それが悪いことは知っていますが、最近まで機能していたので、ずっと使用してきました)。最近の最大の問題はパフォーマンスです。プロジェクトのチェックインとチェックアウトには永遠に時間がかかり、SourceSafe を待つだけで多くの時間を費やしていることに気付きます (はい、ウイルス対策チェックと他のすべてのパフォーマンス ブースト トリックスを無効にしましたが、まだ遅いです)。

現在、代わりにすべてのものをセットアップして Subversion に移行することを検討しています。Subversion と比較して、Web 上の SourceSafe のパフォーマンスはどうですか? 履歴は移動するのにそれほど重要ではないと思います (古いファイルが必要な場合は、VSS データベースに戻るだけです)。ファイルを実際に Subversion に移動することは問題になるはずです。

また、実際の Subversion コア ツールに加えて、「必須」のツールやアドオンについても意見を述べたいと思います。

4

8 に答える 8

13

VSSのチェックインは、SVN ではcommitと呼ばれます。SVN はファイルに加えた変更 (別名「差分」) のみを転送するのに対し、VSS はファイル全体を送信し、サーバー上で差分を送信するため、この操作は何倍も高速です。

SVN でのチェックアウト(最初の作業コピーの取得) は、http(s) を使用していてファイルの全体サイズが大きい (>100MB) 場合、他のシステムと比較してやや遅くなります。HTTP転送は大きな単一ファイルよりもはるかに遅くなるため、SVNの最悪のケースは多くのファイルとディレクトリです。

ただし、VSS が SVN よりも高速になるとは思えません。SVN の全体的なパフォーマンスは、VSS よりも高速で堅牢 (データベースの破損がない) であり、理解しやすいものです。

素敵なツールは、TortoiseSVN(Explorer Plugin)、smartSVn(VSS-lookalike)、およびコマンドライン(柔軟) で、Tigraine が私のコメントに追加しました: AnkhSVN(Visual Studio Integration) および eclipse IDE の subversive/subclipse

于 2008-10-27T10:35:34.613 に答える
8

この質問も関連があるかもしれません。

パフォーマンス

SVN と VSS で個々の操作にかかる時間の主な違いは、SVN の原則にあります。操作の時間は、プロジェクトのサイズではなく、変更のサイズに比例する必要があります。これは、Get latest version (VSS) と Update (SVN) の比較で最もよく見られます。VSS の「最新バージョンを取得」は、常にプロジェクト内のすべてのファイルを反復処理し、それらのステータスを確認します。これには非常に時間がかかります。これに対し、SVN はプロジェクトの履歴を確認し、触れたファイルのみを操作します。典型的なシナリオでは、ほとんどの場合、少数のファイルのみが操作されるため、これは大きなメリットです。ファイルが変更された場合でも、VSS ではファイル全体に比べて変更のみが転送されるため、SVN では VSS よりも変更の転送がはるかに高速です。同じことがコミット (チェックイン) にも当てはまります。大きなファイルで小さな変更を行う場合、ここでも SVN の方がはるかに高速です。

最も重要なツール

Visual Studio 開発者にとって最も重要なツールは次のとおりです。

  • TortoiseSVN - Windows シェル経由でリポジトリにアクセス
  • AnkhSVN - Visual Studio の統合
  • VisualSVNを VS 統合として推奨する人もいますが、AnkhSVN 2 の統合はすでに十分に優れていると思います。

私は、TortoiseSVN と AnkhSVN があれば、「Subversion コア ツール」をインストールする必要はまったくないと言っています。コア コマンド ライン ツールは自動化などに非常に役立ちますが、一般的な日常業務では使用したことがなく、TortoiseSVN や AnkhSVN が機能するためにインストールする必要はありません。

Web アクセス

Web 経由のアクセスは SVN によってネイティブにサポートされており、非常によくサポートされています。VSS の場合、これには外部アプリケーションが必要です。それらは悪くはありませんが、元の環境に対して 1:1 ではなく、速度はまだいくらか不足しています。

変換方法

VSS2SVNは、変換を適度に高速かつ適切に実行するツールです。私たちの経験に基づいて、「安定した」ビルドを使用せず、代わりに毎日のスナップショットを使用することを強くお勧めします。以前のビルドを完全に失敗させる履歴内の多くのアイテムを処理できます。

長い歴史を持つ巨大なデータベースで最近の毎日のビルドをうまく使用しましたが、結果は非常に良好でした.

于 2008-10-27T10:32:37.647 に答える
4

Subversion を使用すると、リモート アクセスがはるかに簡単になります。

履歴を保持する必要がない場合は、VSS から Subversion への移行も簡単です。ソース管理バインディング (*.scc ファイル) を手動で削除するだけです。

ツールに関しては、おそらく TortoiseSVN と、Ankh SVN (無料) のような Visual Studio (それを使用している場合) で使用するためのプラグインを入手したいと思うでしょう。

于 2008-10-27T09:57:09.760 に答える
2

履歴を保持することに関心がある場合は、http://www.pumacode.org/projects/vss2svnが 1 つのリポジトリから別のリポジトリに変換されます。

私はこれで非常に限られた成功を収めました.

于 2008-10-27T10:00:05.760 に答える
2

Visual SourceSafe は、ファイル共有の上に構築されています。したがって、ファイルで予約すると、ファイル システムを使用してすべてが行われます。そのため、ファイルのテキストをサーバーに送信するだけでなく、VSS サーバーにアクセスするときに、VSS はディスクから物理ブロックにアクセスします。共有ディスク ディレクトリ内のファイルの検索などを含みます。これは、クライアント サーバーの特注プロトコルよりも約 10 倍遅くなります。

SourceOffSite と呼ばれる製品があり、VSS データベースに高速なフロント エンドを追加して、VSS を低速のリンクで使用できるようにします。

トニー

于 2008-10-27T11:16:36.807 に答える
1

私の経験に基づいて、それははるかに高速になります。

VSS と SVN で同じ大規模なプロジェクトを使用したことはありませんが、それぞれで異なるプロジェクトを実行し、小規模なものを VSS から SVN に移行しました。

いくつかのものははるかに高速です。特に、多数のファイルをチェックイン/コミットすると、「これには時間がかかり、実際には機能しない可能性があります。とにかく実行しますか?」というような警告メッセージが表示されます。（これは正確に言っていることではありません）。

VSS では、実際には多数の変更をコミットすることは実際には不可能です。複数の小さなコミットを実行する必要があり、プロジェクトを一時的に壊れた状態のままにする必要があります (ただし、アトミック コミットは存在しないため、とにかくある時点で発生します)。 .

于 2008-10-27T10:08:23.263 に答える
0

Subversion については @relentless に同意しますが、コマンド ラインを使用することを好みます。習得には少し時間がかかりますが、一度習得すると速くなります。

また、パフォーマンスが重要な問題である場合は、http://git.or.cz/を参照してください。非常に高速で信頼性が高いと主張されています。

于 2008-10-27T10:05:40.617 に答える
0

TortoiseSVN は確かに非常に優れたクライアントです。これをサーバー上のTracと組み合わせて使用​​し、リポジトリへの Web アクセスと優れた wiki/チケット システムを実現しています。

LiveCD -リンク.

于 2008-10-27T10:30:52.890 に答える