80年代および90年代の当時のマイクロコンピューターでは、バージョン管理はどのように機能していましたか？

プログラマーチームが80年代から90年代前半にソフトウェア開発をどのように管理していたかを知りたいです。すべてのソースコードは、全員が作業した1台のマシンに単純に保存されていたのか、ソースがフロッピーを介して手動でコピーされ、手動でマージされたのか、またはネットワーク（CVSなど）で実際にリビジョン管理システムを使用したのか今？または、おそらくオフラインCVSのようなものが使用されていましたか？

今日では誰もがソース管理に依存しています。それは簡単です。しかし、80年代には、コンピューターネットワークのセットアップはそれほど簡単ではなく、ベストプラクティスのようなものがまだ発見されていました...

70年代と60年代のプログラミングはかなり異なっていたので、リビジョン管理は不要でした。しかし、80年代と90年代に人々がコードを書くためにコンピューターを使用し始め、アプリケーションのサイズと範囲が拡大し始めたので、当時は人々がどのように管理していたのでしょうか。

また、これはプラットフォーム間でどのように異なりますか？AppleとCommodore 64とAmigaとMS-DOSとWindowsとAtariの比較

注：私は主に、大きなUNIXマシンではなく、その日のマイクロコンピューターでのプログラミングについて話しています。

まず、マイクロコンピューターが最初に登場したとき、ソフトウェアは主にUnixまたはVMSシステムで記述され、ターゲットシステムに「クロスコンパイラー/アセンブル」されました。これらのコンピューターシステムは、多くの場合、多くの端末を備えたマルチユーザーであり、SCCSのようなソースコード化された制御システムを備えていました。

ネットワーキングは1980年代半ば以降のマイクロコンピュータのオプションであり、多くの場合、「ファイルサーバー」としてUnixシステムに接続されていました（UNIXシステムのSCCSで、RS232とKermitを使用してファイルを転送するだけの場合もあります）

Eric Sinkによる「バージョン管理の歴史」を参照して、バージョン管理システムが長年にわたってどのように変化したかの概要を入手してください。

1980年代後半に「BYTE」でソースコード管理について読んだことを思い出します。そのため、それまでに「小さなシステム」で使用されていたに違いありません。

SourceSafeは、Dos、Windowsなどで実行されている90年代半ばまでに確立されました。

このリンクは1994年からPCで実行されているPVCSに関する記事を示しています。バージョン6.2であるため、しばらく前から明らかにされていたと、ウィキペディアは1985年からのものであると述べています。

しかし、1990年代後半まで小規模ソフトウェアに取り組んでいるほとんどのプログラマーは、番号付きのフロッピーディスクを使用して、ハードディスク上のフォルダーに置き換え、毎日ソースコードのコピーを作成していました。

UnitからWindows NT 3.5にソフトウェアを移植するプロジェクトで作業したことを覚えています。Windows用のプログラミング方法を知っているプログラマーは、その時点でソースコード管理のことすら知らなかったことがよくありました。

このタイムラインはcodicesoftwareによるブログ投稿から取られており、Plastic SCMを販売していますが、他のシステムの歴史の概要は妥当と思われます。RCSが残る前のいくつかの古いシステム。

これはおそらくゲーム業界全体を代表するものではありませんが、小さなゲーム会社ではうまく機能しました。他の要件があると思われるビジネスソフトウェアを使用したことがない。

80年代半ばから90年代半ばまで、ファイル名の最後にバージョン番号を使用することがよくありました（例： "game.003"）。当時私はアセンブラーで90％をプログラミングしていましたが、すべてのコードは1つまたは2つのインクルードを持つ単一の巨大なファイルにありました。安定したバージョンを保持した後、番号をインクリメントするだけです。

これにより、最終的には3人程度まで多少快適になりました。その後、私たちはチームを成長させ、最終的には1年かそこらの場所にファイルを散らかし、個々の人々の変更を追跡しようとすることにうんざりし、1997年から98年頃にPerforceを使い始めました。

これは、当時の一般的なインフラストラクチャのコンテキストで確認する必要があります。80年代初頭、IBMは「パーソナルコンピュータ」をリリースしました。これは文字通り理解できます。PC用のアプリケーションを開発する最も一般的な方法は、何かを作成して販売しようとする1人の男でした。したがって、リリースされたバージョンごとに1枚のフロッピーディスクがおそらく一般的です。素敵なカラフルなラベルを買って、製品の名前とそのバージョンを書くことができます。当時の成功した製品のほとんどについて、あなたはそれを書いた男の名前を知っていました。

ネットワークはアドオンとして導入されました。クライアントAPIはDOSにハッキングされ、サーバー部分は別のマシン上の専用の専用オペレーティングシステムでした。通常は（大衆向けではなく）高価で、基本的にはファイルとプリンターの共有のみを提供します。PCの世界では、Windows for WorkgroupsとWindows NTの導入により状況が変わり始めました。それは多くの可能性を開きました。プログラマーが使い慣れた環境にネットワークがついに統合され、Windowsプログラマーはネットワークを介して相互に通信できるアプリケーションを作成できるようになりました。これが、支配的なネットワークオペレーティングシステムとしてのNetWareの終わりでした。

すぐに、クライアントとサーバーのコンポーネントを備えたいくつかのバージョン管理システムがポップアップし、マシンの任意の組み合わせに簡単にインストールできます。ビルドシステムでの統合を可能にするコマンドラインオプションをサポートするIDEおよびクライアントコンポーネント用のプラグインを使用します。

Webが離陸し、インターネットへのPCアクセスがユビキタスになった後、オープンソースの動きとWebベースのソース管理システムが手に入りました。面白いことに、PCが導入されたとき、これは集中型コンピューティングから分散コンピューティングへの大胆な動きと見なされていました。しかし、中央と分散の定義は曖昧になっています。クラウドは究極のディストリビューションですか、それとも、IBMメインフレームのように、すべてのパワーを保持する新しいモンスターセントラルコンピューターですか？

90年代、私は間違いなくバージョン管理にソフトウェアを使用していました。SCCSがあり、AppleのMPWには組み込みのバージョン管理（プロジェクター）がありました。そして、私は1992年頃にProjectorを使用したと思います。ある会社では、バージョン管理システムはすべてのバージョンのフロッピーディスクを備えた大きな食器棚で、週に1回撮影されました。

私がまだ学校に戻っている間の私の最初の夏のプログラミングの仕事（これは私が思うに91年頃だったでしょう）は、私が働いていた小さな会社に自動バージョン管理とバックアップシステムを実装することでした。3台のPCをネットウェアサーバーに接続し、所有者は最終的にバージョンの競合を処理し、フロッピーにバックアップする必要があるものを処理するのにうんざりしていたため、開発者はサーバーに保存されたファイルではなく、自分のPCで作業するようにしました彼らがこれまで持っていたように、誰も使用していないことを確認するプログラムを実行するまですべてのファイルを読み取り専用に設定し、中央のbtrieveデータベース（単純なクエリを使用するリレーショナルデータベース）に使用を記録するシステムを作成しましたnetwareサーバーで実行された完全なsqlではなく、api）。別のプログラムが変更内容をチェックアウトしてサーバーにコピーし、

このシステムは私が働いていた中小企業向けに特注したものでしたが、多くの同様のショップには同様のプロセスがあったと思います。

個人的な経験から：1985 MS-DOSネットワーク開発PVCSは入手可能で高価すぎました。Appleおよびすべての非MSDOS PCの場合：何もありません。私は1987年からT-lib（50ドル）を使用しました。Unixポート（SCCS）は、1990年頃からフィルタリングを開始し、1992年頃にはSourceSafeを使用し始めました。

1995年までに、VCSを使用していなかったとしても、深刻ではありませんでした。

1993年から1995年にかけて、私は15人の開発者と年金管理者を務め、SPARCStation 20sとSun IPXを使用してSunOSでC / C ++開発を行いました。コードベースはNFSマウントされたディレクトリにありました。当初はコピーフォルダのバージョン管理を行っていましたが、ある時点でSCCSに移行し、一部のチームはRCSの使用を開始しました。

1995年に、80人以上の開発者がニューヨーク、ロンドン、香港でC / C ++開発を行っている別の会社に移りました。ClearCaseとマルチサイトアドオンを使用して、開発環境を管理しました。

ClearCaseは、サイト間でコードベースを同期することは得意でしたが、当時は、常にフルタイムの管理者が作業を続ける必要がありました。また、ClearCaseは仮想ファイルシステム内のファイルを提示し、ブランチ、時間、および/またはタグに基づいてディレクトリのバージョンとワイルドカード化されたファイル名を指定する構成でファイルを提示するため、はるかに遅くなりました。病理学的なケースでは、個々のファイルごとに異なるバージョンを指定できます。