ホストコンピュータ時代のソース管理方法を教えてください。現在はSVNなどのバージョン管理ソフトがあったりして、便利ですが、ソースをフォルダー管理などで、間違って削除、上書きしてしまうような環境下での安全なソース管理が知りたいです。多分運用がどうのと言う話になるのかとは予想しますが。

回答の条件
  • 1人10回まで
  • 登録:2010/10/31 16:07:17
  • 終了:2010/11/04 22:11:04

ベストアンサー

id:a-kuma3 No.3

a-kuma3回答回数4489ベストアンサー獲得回数18572010/10/31 16:57:27

ポイント28pt

ホストコンピュータでも、ソース管理システムは昔からあったんです。

富士通の OSIV だと PowerGEM ってのがありました。

unix の SCCS だって、もとは IBM の汎用機用に作られたものだったはず。


ただ、有料だってことと、コスト意識が今とは違ってたので、使ってるプロジェクトは見たことがありませんでした(ぼくのまわりだけかもしれませんが)。


ソース管理は、台帳で管理してました。

修正がしたくなったら、台帳で修正番号を取ります。

ソースを修正するときには、古いコードをそのままコメントアウトし、その近くに新しいコードを書いて、

修正番号を記したコメントを記載します。


ファイルのバックアップは、定期的に行います。

週に一回とか決めて、ライブラリ単位、もしくは、ディスク一括でテープにバックアップを取っておきます。

テープは世代管理してて、2~3世代くらい残しておくのが普通だったかな。

もし、間違いが起きたら、三週間前までには戻れる、見たいな感じ。


一応、今と同じようなことは、何とか出来てはいました。

でも、昔の状態に戻すのが、大変でしたね。


バックアップがテープにしかないので、リモートで昔の状態に戻すには、物理的にそのマシンのところに行かなくてはいけない。

最低でも、ライブラリ単位で全部戻ってしまうので、共通資源を戻すときには、事前の調整があれこれ大変だった。

diff コマンドに相当するものが無かったので、差分を確認するのが、また大変。


話はそれますが、SVN を使ってるのに、古いソース管理から抜け出られないプロジェクトもあるみたい。

  • 昔のコードはコメントアウトして残しておかなければいけない

  • 同じ資源に対して、レポジトリが複数ある (なんで、そんなことになったのか...)

  • 修正番号を台帳管理してて、取得しないとコミットできない

などなど。


以上、参考になれば。

id:nigredo

この場合バックアップが主な間違いへの担保なんですね。なるほど。ありがとうございます。



>話はそれますが、SVN を使ってるのに、古いソース管理から抜け出られないプロジェクトもあるみたい。

>・昔のコードはコメントアウトして残しておかなければいけない

>・同じ資源に対して、レポジトリが複数ある (なんで、そんなことになったのか...)

>・修正番号を台帳管理してて、取得しないとコミットできない

>などなど

 うーん、これは身につまされます。わかるわかる。

2010/11/01 10:27:02

その他の回答(7件)

id:windofjuly No.1

うぃんど回答回数2625ベストアンサー獲得回数11492010/10/31 17:17:35

ポイント19pt

【1】記憶容量の変遷から見た推移

(1)HDDどころかFDDも無かった時代

ルーチン単位にマークカードを紐で括って表紙がつけてあり、

ルーチン名や概要ならびに作成日や作成者などが記入してありました

それとは別に全体の管理はノートにまとめられていました(ルーズリーフではなくノートがよかったようです)

いずれも手書き文書です。SVNの管理部分をすべて紙の上で行っていたと想像してもらえればよいと思います

(2)FDD時代

世代毎にFDDを分けてました。旧世代がそのままバックアップの意味もかねてましたね

(3)HDD時代

バージョン管理はディレクトリ単位にしてましたが、この時代に入っても紙媒体による管理は主ですね

(4)ネットワーク時代

大量のパソコンでネットワークを組むようになってくるとSVNのような管理ソフトは必須ですね

だからといって紙媒体による管理が完全になくなっているというものでもなくて、

特におおよその部分を知りたい場合には紙媒体のほうが便利だったりもしますね

 

【2】コンピュータ普及度から見た推移

(1)1970年代

ホストコンピュータで動作するソフトの開発は、

大学やハードウェア開発会社に所属する一握りの人だけが行えました

利用者は専用端末からマークカードやテープ、一部ではFDDを使い、

利用の度にデータをアップロードして計算させるという流れになってました

(2)1980年代

データ作成にパソコンが使えるようになり便利になりましたが、

ホストコンピュータですらも今のUSBメモリにすら遠く及ばない程小さな記憶しかできず、

ホストで動作させるのはプログラムというよりはバッチ処理を書く程度の短いものだったため、

バージョン管理は前述したFDD時代のもので十分でしたね

(3)1990年代

パソコンの性能が飛躍的に伸び、ホストコンピュータ同様の計算をパソコンだけで行えるようになってきましたが、

HDDも高価で、現代の携帯電話にも及ばない程度の記憶容量でしたから保存はFDD時代同様にFDDで世代毎にしたり、

少し贅沢な環境ではHDDを複数用意して付け替えるなどの方法を取っている場合などもありました

(4)1990年代後半から現代

一般家庭でもLANが組める程にパソコンが普及しはじめました

この頃から一般企業などでもSVNなどのバージョン管理ソフトは必須となってきましたね

 

【3】いきなりまとめ

古い時代を思い起こして懐かしみつつ、ざっくりと書きましたが、

いつの時代においても(紙の上かHDDの上かの違いはあるのせよ)下記2点が重要なことは変わりないように思いますね

(1)設計時にどこまで考えてあるか?

(2)実施時にどこまで作業手順を守れるか?/守らせることができるか?

上記2点がしっかりしていれば間違って削除や上書きなどはまず起こりえない事ですし、

システムトラブルが原因だったとしてもバックアップから書き戻せばよいだけの話となります

古い人間と言われてしまいそうですが「まちがって削除なんてのは気が抜けている」と言ってしまいますね

SVNなどの便利なツールはありますけれど、使うのは人間であって、SVNなどに人間が使われてしまってはいけないです(笑)

id:nigredo

(1)設計時にどこまで考えてあるか?

(2)実施時にどこまで作業手順を守れるか?/守らせることができるか?

多分そうでしょうね。この中で(2)の作業手順等、詳しく突っ込んだ回答があれば尚よかったです。ありがとうございます。

2010/11/01 10:24:16
id:hgijgbnfhfg No.2

hgijgbnfhfg回答回数116ベストアンサー獲得回数02010/10/31 17:27:06

(はてなにより削除しました)
id:nigredo

ワオ!スパムですね。

クリック注意

2010/11/01 10:22:42
id:a-kuma3 No.3

a-kuma3回答回数4489ベストアンサー獲得回数18572010/10/31 16:57:27ここでベストアンサー

ポイント28pt

ホストコンピュータでも、ソース管理システムは昔からあったんです。

富士通の OSIV だと PowerGEM ってのがありました。

unix の SCCS だって、もとは IBM の汎用機用に作られたものだったはず。


ただ、有料だってことと、コスト意識が今とは違ってたので、使ってるプロジェクトは見たことがありませんでした(ぼくのまわりだけかもしれませんが)。


ソース管理は、台帳で管理してました。

修正がしたくなったら、台帳で修正番号を取ります。

ソースを修正するときには、古いコードをそのままコメントアウトし、その近くに新しいコードを書いて、

修正番号を記したコメントを記載します。


ファイルのバックアップは、定期的に行います。

週に一回とか決めて、ライブラリ単位、もしくは、ディスク一括でテープにバックアップを取っておきます。

テープは世代管理してて、2~3世代くらい残しておくのが普通だったかな。

もし、間違いが起きたら、三週間前までには戻れる、見たいな感じ。


一応、今と同じようなことは、何とか出来てはいました。

でも、昔の状態に戻すのが、大変でしたね。


バックアップがテープにしかないので、リモートで昔の状態に戻すには、物理的にそのマシンのところに行かなくてはいけない。

最低でも、ライブラリ単位で全部戻ってしまうので、共通資源を戻すときには、事前の調整があれこれ大変だった。

diff コマンドに相当するものが無かったので、差分を確認するのが、また大変。


話はそれますが、SVN を使ってるのに、古いソース管理から抜け出られないプロジェクトもあるみたい。

  • 昔のコードはコメントアウトして残しておかなければいけない

  • 同じ資源に対して、レポジトリが複数ある (なんで、そんなことになったのか...)

  • 修正番号を台帳管理してて、取得しないとコミットできない

などなど。


以上、参考になれば。

id:nigredo

この場合バックアップが主な間違いへの担保なんですね。なるほど。ありがとうございます。



>話はそれますが、SVN を使ってるのに、古いソース管理から抜け出られないプロジェクトもあるみたい。

>・昔のコードはコメントアウトして残しておかなければいけない

>・同じ資源に対して、レポジトリが複数ある (なんで、そんなことになったのか...)

>・修正番号を台帳管理してて、取得しないとコミットできない

>などなど

 うーん、これは身につまされます。わかるわかる。

2010/11/01 10:27:02
id:yossiy7 No.4

勇者よっしー回答回数778ベストアンサー獲得回数962010/10/31 21:05:26

ポイント10pt

昔から色々ありましたが、プログラマの間ではCVSが鉄壁ですね。

インストールが簡単なので、無能管理者はすぐVSS使いたがりますが、VSSはソース自体にバージョンを持たせる機能が無いので、歯抜けが発生しても許容してしまうという根本的な弱点があります。

CVS使っておけばまずOKです。OSSでも大抵はCVSです。

id:nigredo

うーん、この質問の事の発端としては、SVN,(CVS,VSS、GIT等などを含んだと言う意味合いで書きました)が使えないプロジェクトがあり、その場合、どうしてもそれらのバージョン管理ソフトが使えない時代(ホスト時代など)の時の安全なソース管理はどうやっていたのだろうと言う疑問があり、ここに質問しました。ごめんなさい、こちらの質問の仕方がちょっと不明瞭なために質問と回答がずれているような気がします。

2010/11/01 10:31:51
id:a-kuma3 No.5

a-kuma3回答回数4489ベストアンサー獲得回数18572010/11/01 15:25:01

ポイント19pt

この質問の事の発端としては、SVN,(CVS,VSS、GIT等などを含んだと言う意味合いで書きました)が使えないプロジェクトがあり、その場合、どうしてもそれらのバージョン管理ソフトが使えない時代(ホスト時代など)の時の安全なソース管理はどうやっていたのだろうと言う疑問があり、ここに質問しました。

なんとなく、想像の範疇内だった :-)


バックアップが担保というよりは、管理台帳が「要」だったと思います。

バックアップも、媒体を台帳で管理していました。

管理上は、「履歴(台帳)」が【主】で、「ソース」は【派生物】です。


そういうふうに理解できないと、修正の作業自体がかなり苦痛なので、CVS のような管理ツールがはやるのも当たり前かな、と。

先の回答で例に出したプロジェクトでも、使い方は間違ってる ものの、導入だけはしてます。

サーバが用意できないとかの費用的な側面があるんですかね。

id:nigredo

>管理上は、「履歴(台帳)」が【主】で、「ソース」は【派生物】です。

 なるほど、必ず台帳を起点として作業を出発させると言う感じですかね。

>サーバが用意できないとかの費用的な側面があるんですかね。

 「(バージョン管理ソフトを入れられないのは)サーバが用意できないとかの費用的な側面があるんですかね。」という風に理解した上で書くのですが、経験上ですが、多くは慣れの問題(ヒトの感情的な問題)でしょう。今まで慣れてきた管理方法と異なる方法で同じように管理しきれるかという不安。まぁ、書いていたただいたように、SVN屋さんが「管理上は、「履歴(台帳)」が【主】で、「ソース」は【派生物】です。」という発想の転換が必要なように、慣れ以前の問題より、ソース管理方法の発想の転換ができるかどうかだとは思っておりますが。


 また、いくら運用で、運用の徹底、手順の徹底と言ったとしても間違えるのが人間なので、その間違いのリスクを減らすためにもバージョン管理ソフトは必要なのですが、そのリスクに晒されたヒトでない限りはあまり必要とは思わないでしょうし。

 あと、あるとしたら、企業的なコンプライアンス上、不要なソフトは入れられないといったもの。これはどうしようにも無い。

2010/11/01 20:02:53
id:a-kuma3 No.6

a-kuma3回答回数4489ベストアンサー獲得回数18572010/11/02 00:29:51

ポイント18pt

SVN屋さんが「管理上は、「履歴(台帳)」が【主】で、「ソース」は【派生物】です。」という発想の転換が必要なように、慣れ以前の問題より、ソース管理方法の発想の転換ができるかどうかだとは思っておりますが。

今では、発想の転換が必要なのは、「今までの管理方法に慣れている」人達なんだと思いますけどね。

もちろん、ある程度の交通整理は必要だと思いますけど、実験的な修正であれば、とりあえずブランチを切っておくとか、やりかたはいろいろあるし、いつでも戻せますから。


昔の人が、SVN 等を触ったことが無いんで、具体的な指示が出せないんですよね。

SVN を知っている人が、具体的な管理方法を提案してあげるしかないと思います。

ポイントは、「昔と同じことができる」ことと、「昔よりも楽にできる」ことだと思います。


ぼくが、いまやってるプロジェクトでは、修正の台帳管理もしてますけど、コミットと台帳登録の後先は、あまりうるさく言わないことにしてます。

ルールは、以下の四つくらい。

  • ビルドエラーが起きない状態でコミットする

  • コメントには、何の修正をしたか分かるように書く(「修正」とかで済ませない)

  • 意味の単位でコミットする(例えば、機能追加とリファクタリングを同時にコミットしない)

  • 共有の id を使わず、個人の id でコミットする

何かをやらかしたときでも、すぐ元に戻せますし、いつだれがやらかしたのかも、完全にトレースできますし。


# って、nigredo さんは分かってるのか :-)

id:nigredo

>昔の人が、SVN 等を触ったことが無いんで、具体的な指示が出せないんですよね。

ま、これに尽きますね。

>SVN を知っている人が、具体的な管理方法を提案してあげるしかないと思います。

>ポイントは、「昔と同じことができる」ことと、「昔よりも楽にできる」ことだと思います。

 大概は、(昔の管理者達が覚えようとしないのは置いておいて)SVN管理になれたヒトたち

の悪いところは昔の管理者達に、今の管理方法に変更する利点ってのが提示できできないのが

一番なんでしょうけど。


>・ビルドエラーが起きない状態でコミットする

>・コメントには、何の修正をしたか分かるように書く(「修正」とかで済ませない)

>・意味の単位でコミットする(例えば、機能追加とリファクタリングを同時にコミットしない)

>・共有の id を使わず、個人の id でコミットする

 この辺は定番ですね。昔の管理者達は、これが開発者が**勝手に**いつでもコミットしてしまう

と言うのが嫌らしい。あくまで管理者がやらないと駄目とか。グチを言っても仕方が無い。


閑話休題

 今回の質問について、お聞きします。a-kuma3さんの経験した昔の管理方法でバックアップを取るとありましたが、

これは、毎週などの定期バックアップのほかにも何かバックアップはありましたでしょうか?

たとえば、修正があるたびにバックアップ等。聞きたいのは、たとえばソースが100あるプロジェクトがあったとして、

定期的に100のバックアップを2~3世代と、修正が2つのソースにあった場合に、その修正をリリースする際に

100のバックアップをするなどの運用はありましたでしょうか?

 よろしくお願いします。

2010/11/03 07:25:49
id:a-kuma3 No.7

a-kuma3回答回数4489ベストアンサー獲得回数18572010/11/03 14:41:41

ポイント18pt

これは、毎週などの定期バックアップのほかにも何かバックアップはありましたでしょうか?

たとえば、修正があるたびにバックアップ等。聞きたいのは、たとえばソースが100あるプロジェクトがあったとして、

定期的に100のバックアップを2~3世代と、修正が2つのソースにあった場合に、その修正をリリースする際に

100のバックアップをするなどの運用はありましたでしょうか?

あくまでも、ぼくの経験です。


まず、定期的なバックアップの単位は DASD でしたね。

ソースが何本あろうが、一括でバックアップ。


それよりも短い間隔でのバックアップはライブラリ単位ですね。

大きな機能単位でライブラリが分かれてたので、自分が担当する範囲のライブラリをバックアップ。

定期的なバックアップがあったので、間隔は担当者任せ。


リリース単位のバックアップって取らなかったですね。

納品のタイミングでは、納品用と、それの写し、って意味ではバックアップを取りましたが。

開発中は、修正を入れる前にバックアップを取る、という方が多かった記憶があります。

なんせ、媒体がテープなので、戻すのが大変で。

ソース単位で戻すときには、一覧を見るために一度テープをセットして、戻すときに、もう一度セットしなおして、って感じですから。

バックアップの際には、リストも紙に出力していましたが、よく無くしましたし。


個人的には、割とソース単位のバックアップを取るようにしてました。

よく使ってた機種が、5 inch のフロッピーが使えたので、いざというときに、パソコンでソースを見られるからです。

バックアップというよりは、今で言うと同期化という方が近いでしょうか。


昔の管理者達は、これが開発者が**勝手に**いつでもコミットしてしまう

と言うのが嫌らしい。

ぼくが苦労したのは、昔風の修正履歴の残し方ですね。

修正前のコードを削除してはいけなくて、完全にコメントアウトしなきゃいけない、ってルールがあって。

片方で台帳管理してるくせに、コードを削除すると、何がどうなったか分からなくなるから、って。


行単位のコメントがすだれのようになってて、目の前に見えているコードで生きているのは 10分の1 程度なんてことはザラでした。

で、開発者当人も嫌だったのか、全コードをコメントアウトして、新しいコードを下に書きなおした奴も居て。

どこを直したか分からないっつうの。


こういうのを無くせるのが、今どきのやり方の利点だと思いますね。


以上、参考になれば。

id:nigredo

なるほど、簡単にまとめると、

  • 定期的なバックアップを取る(プロジェクトの正式な運用)
  • ライブラリ(多分担当された機能単位)でのバックアップを取る(プロジェクトで正式なものではない?担当者の防御策のような意味合い?)
  • リリース単位でのバックアップは取らず、修正前(開発前)にバックアップを取る

 と言うところがポイントになるのでしょうか?

>行単位のコメントがすだれのようになってて、目の前に見えているコードで生きているのは 10分の1 程度なんてことはザラでした。

>で、開発者当人も嫌だったのか、全コードをコメントアウトして、新しいコードを下に書きなおした奴も居て。

>どこを直したか分からないっつうの。

 あるある、正直美しくないですね。

2010/11/03 22:02:44
id:a-kuma3 No.8

a-kuma3回答回数4489ベストアンサー獲得回数18572010/11/04 16:57:15

ポイント18pt

コメントがつけられないので、回答でコメントします。

リリース単位でのバックアップは取らず、修正前(開発前)にバックアップを取る

これは、僕が経験した汎用機系プロジェクトで、そうだった、というだけで、リリース単位のバックアップはあった方が良いと思います。

きっと、パッケージを開発しているような部隊だと、リリースごとにバックアップを持っていたと思います。

id:nigredo

なるほど、経験談ありがとうございます。

プロジェクトの参考にしたいと思います。

質問については、これで締め切らせていただきたいと思います。

2010/11/04 22:05:04

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません