各ファイルを個別にバージョン管理するバージョン管理システムの利点は何ですか？

15

過去数年にわたって、私はいくつかの異なるバージョン管理システムを使用してきました。私にとって、それらの間の基本的な違いの1つは、ファイルを個別にバージョン化するか（各ファイルには独自のバージョン番号と履歴がある）、リポジトリ全体（「コミット」またはバージョンがリポジトリ全体のスナップショットを表す）である。

一部の「ファイルごと」バージョン管理システム：

  • CVS
  • ClearCase
  • Visual SourceSafe

一部の「全体リポジトリ」バージョン管理システム：

  • SVN
  • ギット
  • マーキュリアル

私の経験では、ファイルごとのバージョン管理システムは問題を引き起こすだけであり、正しく使用するにはより多くの構成とメンテナンスが必要です（たとえば、ClearCaseの「構成仕様」）。同僚が無関係なファイルを変更し、理想的には孤立した開発ラインを壊すという多くの事例がありました。

これらのファイルごとのバージョン管理システムの利点は何ですか？「全体リポジトリ」バージョン管理システムには、ファイルごとのバージョン管理システムにはない問題がありますか？

version-control 
— マイク・ダニエルズ
ソース
3
主に歴史的にそのようなものであり、ファイル指向からチェンジセット指向のシステムに移行しつつあると思いますが、今日の観点からは、なぜファイルごとのアプローチを試みたのか理解するのは困難です。素晴らしい質問です！
— -blubb
この質問が議論の余地があるとして謝罪します。これは最近の不満の産物です。
— マイクダニエルズ
1
@マイク・ダニエルズ：利点を明確に求めているので、（少なくとも私には）そうではありません。
— -blubb
これらの2つの視点は、単に異なる規則です。一方より他方を支持する議論は、反対側のパルチザンからの反論を提起するだけです。たとえば、Clearcaseで「whole-rep」動作が必要な場合は、日付ごとに構成仕様をカスタマイズできます。
— -mouviciel
SVNにはファイルごとのバージョンがありますか、それとも最後のバージョンでも変更されましたか？
— クライム

回答:

3

ファイルごとに、同じリポジトリから製品ライン（複数のソフトウェア製品）を構築するときに利点があります。

一部の顧客契約環境では、コードド​​ロップのみに必要な変更があり、他の変更はないという証拠が必要です。ファイルのバージョン番号がすべて同じである場合、これは非常に簡単です。

そして、これは私が薄い空気から引き出したランダムな例ではありません。

これは、前の雇用主から大量に購入したシステムのソフトウェアアップデートを米国軍に最後に出荷したときに起こりました。契約のドル価値は、数十億ドル単位で測定されました（米ドルの価値がはるかに高かった頃）

だからそれは時々助けになります。

奇妙なことに、私が現在働いている場所では、お客様ごとに異なる成果物も出荷しています。

シュリンクラップやWebアプリよりも防衛/航空宇宙分野でよく見られると思います。

— ティム・ウィリスクロフト
ソース
3
しかし、ファイルリポジトリ全体のブランチも同じニーズを満たします。たとえば、bzrでは、マージ（またはリポジトリを共有）までブランチはメインラインから完全に独立しています。
— edA-qa mort-ora-y
1
「ファイル全体」VCSで使用するファイルを決定するために、VCSの外部の状態に依存するよりも、「全体リポジトリ」システムのブランチが必要な状態をより良く表現できないという単一の状況を考えることはできません。uniの後の私の最初の仕事は、RCS、多数のスクリプトを使用してプロジェクトをバージョン管理し、トップレベルのスクリプトを使用してバージョンスクリプトをバージョン管理しました。これは絶対的な悪夢でした。* 8 '）
— マークブース
@Mark Booth、顧客は、どのファイルが必要な修正のために変更されたかを知っていました。そのため、物理的な構成の監査はバージョン管理番号によって行われました
— ティムウィリスクロフト
私が言っているのは、バージョン+監査済みパッチには、VCSと監査人という異なる場所で異なる情報が必要だということです。「全リポジトリ」システムのブランチでは、これらの2つの状態は個別のエンティティとして記録されます。これで、同じ情報がVCSと監査システム間で複製され、常に一致するはずです。git作成者とコミッターを区別することもできるため、パッチの作成者（作成者）と監査者（コミッター）の両方を知っている「監査済み」リポジトリを保持できます。模範的な状況を教えてください。-1を逆にします。
— マークブース
@Markブースのパッチ ソフトウェアがこのファイルセットであることがわかっていたA 1.01 B 1.05 D 1.55 E 1.44 F 1.01および受け入れたバージョンのSVDにはファイルごとの変更情報が含まれていました。たとえば、Eは欠陥1104を修正するために変更されました。Fをバージョン1.01から変更した場合、天国は私たちを助けてくれます。修正された実際のバグがあり、変更を望まないため、状況はさらに複雑でした。これらの人々は、1年の開発から厳選された一部の機能のみをピックアップするために、最小限の変更セットを望んでいました。事後バグ修正の選択。
— ティムウィリスクロフト
0

「ファイルごと」のバージョン管理システムには、VCSの実装以外の明確な利点はないと言えます。VCSのコーダーは、「ファイルごとの」バージョン管理の場合に喜んでコーディングします。歴史的に浮かび上がってきた点に同意します。

— アービンド・シンニア
ソース
0

関連ファイルがある場合、ファイルごとのアプローチには利点がありません。これは、開発設定で最も一般的なケースです。

いくつかの特殊な場合-/ etcまたは。Unixのホームディレクトリにあるファイルは、私が日常的に持っている唯一のファイルです。（ほとんど）無関係なファイルを処理しています。そして、無関係な変更を同期させることを主張するシステムを持つことは厄介なことです。

— プログラマー
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.