ソース管理が発明されたのはいつですか?


20

私は多くのバージョン管理システムを知っています:CVS、SVN、TFSなど...

私は最初の「リビジョン管理/バージョン管理システム」をグーグルで調べましたが、さまざまな矛盾する答えがありました。

ソース管理が発明されたのはいつですか?誰が発明したのですか?それは何と呼ばれていましたか?



18
実際に何度も発明されましたが、彼らはソースコードを失い続けました。
-Reactgular

4
「ソース管理」の定義方法によって異なりますが、IBMのIEBUPDTEは1962年にさかのぼり、おそらく最も初期のVCSでした。
ロスパターソン

2
ファイルシステムのバージョン管理をリビジョン管理に同化できる場合、これは1960年代に遡ります。
ムーヴィシエル

@RossPatterson、そのコメントは本当に答えが必要です。
ジョンR.ストローム

回答:


14

ここでかなりまともなタイムラインのビデオ形式(無音)における主要なプレーヤーのは。

SCCSが最初であり、約9年のマージンがあることを示唆しています。

http://i.stack.imgur.com/wcAWD.png

しかし、このブログとその結果のコメントから明らかなように、そこには多くの欠落があります。


7
SCCS元の論文は、他のシステムについては言及しておらず、用語自体を考え出さなければならなかったことを示しているようです。そのソースだけから見ると、1972/73以前にはバージョン管理システムがなかったように見えます。
マーティンピーターズ

1
ソースコード管理システムに「ソースコード管理システム」という名前を付けることは、それが後にソフトウェアカテゴリになる何かの最初のインスタンスであることを示しています。
インゴ

@MartijnPieters Rochkindは、この論文の最後にあるBrownのCLEARを認めており、簡単に言えば、OS / MVTでSCCSを構築すると、IEBUPDTEに気付かなかったはずです。
ロスパターソン

@RossPatterson:CLEARもIEBUPDTEもソース管理システムではありません。CLEARはデルタのアイデアの功績であり、他の類似点はないことを論文で明確に述べています。
マーティンピーターズ

3

1981年、テキサス州オースティンのCharter Informationで夏の仕事をしました。以前はマサチューセッツ州ウォーバーンのコマーシャルインフォメーションコーポレーションでした。彼らはシグマ7にフィールドアップグレードされたゼロックスシグマ6を実行しました。ソースコード管理にはSPUD(ソースプログラムアップデート)と呼ばれるものを使用しました。テープベースでした。

私は定期的に「二百周年記念SPUDテープ」をマウントし、そのテープ上のコードのMODデッキで作業しました。1976年に作成されたため、「2世紀に渡るSPUDテープ」と呼ばれていました。彼らは古いテープを持っていたため、SPUDが1976年よりも遡ったことを示しています。

UTオースティン(1973-1981)の学生の間に、CDC 6600以降のメインフレーム用のControl Data Corporationの2つのソースコード管理プログラムであるMODIFYとUPDATEに出会いました。彼らが最初に出てきたのはいつかわかりませんが、1960年代後半に出てきた(記憶が私に役立っているなら)6600のすぐ後に出てきたのではないかと思います。

私は、IBMが他の誰よりもずっと前に何かを持っていたのではないかと疑っていますが、IBMメインフレームの歴史についてまったく知識がなく、そのように気に入っています。


CDCのMODIFYおよびUPDATEコマンドは、ソフトウェアの更新を適用するためのユーティリティであり、自分のソフトウェアの変更を管理するためのものではありません。参照してくださいapps.dtic.mil/dtic/tr/fulltext/u2/a208003.pdfページのユーティリティについて説明し、ページが(PDF 61)52番、そしてcomputinghistory.org.uk/downloads/39256について説明し、 #4のソフトウェアリリース資料(PDF#16)がUPDATE形式で提供されます。
マーティンピーターズ

Xerox SPUDS(ソースプログラムアップデートディスクシステム)も同様のパッケージだと思います。
マーティンピーターズ

2

IEBUPDTEのもともとIBMのOS / 360システム用に作成されたプログラムは、日付がより10歳年上、1962年にバックSCCS。その目的は、一連の変更を一連の入力ソースプログラムに適用し、一連の変更されたソースプログラムを作成することです。すべてのソースコードは、80列のパンチカードの「デッキ」として、またはそれらに似たファイルとして管理されていました。これらのソースプログラムデッキには、各行またはカードの固定列セットに「シーケンス番号」がありました(COBOL列1〜6で左に指定し、他のほとんどすべては列73〜80で右にあると想定しました。シーケンス番号は1行ずつ増やす必要がありましたが、ほとんどのソースコードは10秒、100秒、または1000秒増加し、2行間の整数のスペースに後で挿入できるようにしました。

典型的なIEBUPDTEコントロールデッキは次のようになります。

./ CHANGE NAME=PROG001
         PROGRAM XYZZY                                                  00005000
./ DELETE SEQ1=9000,SEQ2=15000
         DO I=1,10                                                      00026000
./ CHANGE NAME=PROG002
         J=256                                                          00092000
./ ENDUP

2つのソースファイル「PROG001」および「PROG002」を変更し、行番号「5000」を置換します(多くの場合、5番目の行は「数千」の慣行に従います)。 。

最も単純なレベルでは、それがソース管理の定義です。Unixの人々は、パッチが行うこととしてそれを認識しますが、暗黙の代わりに明示的な番号付けを使用します。コントロールデッキのセットを順番に入力プログラムに適用し、それらのセットを結合ディスクファイル(Partitioned Dataset)として保存するのが一般的でした。これは、CVSRCS,vファイルに保存する変更履歴と非常に類似しています。IBMは、頻繁に呼び出されるコードのパッチを送達するプログラム一時修正単一の関連チェンジの一部としてファイルを変更し、大きなコントロールデッキの形で(PTFの)のSubversionGitのユーザーが使い慣れた見つけるだろう。


IEBUDTEはソフトウェア更新システムではありませんか?パッチに似ているため、せいぜいバージョン管理システムのコンポーネントです。私が知る限り、時間の経過に伴う変化のグラフはありません。
マーティンピーターズ

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