JPH04102138A - ファイル管理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、大規模または遠隔地間でのソフトウェア研究
・開発環境の維持を自動的に行い、研究・開発の効率を
向上させるシステムに関する。

〔従来の技術〕

多人数でソフトウェアを研究開発するような場合、複数
人数で共有する必要のあるファイルを共用ファイルサー
バに入れて相互に利用する形態をとる。さらに大規模な
プロジェクトでは複数ＬＡＮ（ローカルエリアネットワ
ーク）にまたがって共有する必要性がでてくるため、同
一の内容を持つファイルサーバ（共用ファイルサーバ）
を複数用意し共有する必要のある地区に配置する。

しかし、共有ファイルに修正が加えられた場合や共存フ
ァイルが増えた場合などは、各共有ファイルサーバへの
更新を人手で行う必要があり、共用ファイルサーバの管
理には多大な労力を強いられた。

この問題を解決するため、本発明者らは、各ＬＡＮにリ
リースサーバを設け、このリリースサーバ内に、ファイ
ルの存在位置等の属性を表すＩＪ　ＩＪ−スマップを記
憶する手段を設けて、複数のＬＡＮ間におけるファイル
サーバへのファイル転送とＩＪ　ＩＪ−スマツゾの参照
及びＩＪ　ＩＪ−スマツゾが一致していないときは一致
するように書き換える手段を設けたシステムを開発した
。

〔発胡が解決しようとする課題〕

ところが、このシステムだけでは、共有ファイルの更新
がユーザの自由にできていたため、幾つものバージョン
のソフトウェアが生まれやすく、長所を統合した品質の
高いソフトウェアの作成ができにくい環境であった。

そこで本発明は、従来では統一されていなかった共用フ
ァイルサーバでのファイル管理方式に対して、ソフトウ
ェア作成に伴う混乱を防ぎ、ソフトウェア研究・開発の
効率を向上させることを目的とする。

〔課題を解決するための手段〕 本発明のファイル管理方式は、この目的を達成するため
、ソフトウェアを保存しておくだめのファイルサーバを
有し、そのコピーを別の地区のファイルサーバに持つシ
ステムにおいて、各地区にリリースサーバを設け、各リ
リースサーバはファイル名、ディレクトリ、メインテナ
ー、アクセスリスト等の情報を表したリリースマツプを
持ち、このＩＪ　ＩＪ−スマツゾを基に各リリースサー
バ＼が互いにＩＪ　ＩＪ−スマツゾの比較をすることに
よって互いのファイルサーバの内容を一致させるシステ
ムにおいて、 ファイルの更新要求がなされたときに、リリースマツプ
のメインテナーの項と更新要求者とを比較し、異なる場
合にはこのことをメインテナーと更新要求者の両者に確
認をとってからファイルの更新を行うことにより、ソフ
トウェアの共同研究、開発環境の統一性を保つこととし
た。

〔作用〕

リリースサーバはファイル名・ディレクトリ・メインテ
ナー・アクセスリスト・アタッチメント等の情報を表に
したリリースマツプという情報を持ち、共有されるファ
イル群を管理している。

ファイルの更新要求が起こると、このリリースサーバは
ＩＪ　ＩＪ−スマツゾのメインテナーの項と更新要求者
とを比較し、異なる場合にはこのことを両者に電子メー
ルなどで連絡する。該当ファイルの管理者（メインテナ
ー）は、メインテナーを新規更新要求者に変更するか、
メインテナーはそのままでファイルの中身だけ変更する
か、あるいはファイルの変更をさせないかを選択する。

このことによって１つのファイルにメインテナーが複数
存在することをなくし、ソフトウェアの共同研究、開発
環境の統一性を保つ。

〔実施例〕

以下、図面を参照しながら実施例に基づいて本発明の特
徴を具体的に説明する。

第２図に本発明の実施例を示す。Ｌ　Ａ　Ｎ２−１ａ。

２−１ｂ、　２−１ｃ同士を公衆回線などを用いてネッ
トワーク間通信網２−２　を形成しているとき、同一の
内容を持つ複数の共用ファイルサーバ２−３ａ、　２−
３ｂ。

２−３０を用意して利用することがある。この場合各ド
メイン０１．　０２．　０３にリリースサーバ２−４ａ
、　　２−４ｂ。

２−４０を設置することにより、各共用ファイルサーバ
２−３ａ、　２−３ｂ、　２−３Ｃの内容を同一に保つ
ようにすることができる。

第１図に本発明の実施例において共Ｗファイルサーバを
管理するリリースサーバを示す。リリースサーバ１−５
　は制御装置１−１、記憶装置１−２、通信装置１−３
　の３つの部分からなり、記憶装置１−２の内容をもと
に制御装置１−１が通信装置１−３を用いてＬ　Ａ　Ｎ
１−４上につながっているファイルサーバとファイル転
送を行うなどして共用のファイルサーバを管理する。

各リリースサーバは第３図に示すようなファイル名、メ
インテナー、ディレクトリ、アクセスリストを示すリリ
ースマツプを持ち、この情報を基に共用のファイルサー
バを管理する。

ソフトウェアのリリース要求を受けた時のリリースサー
バの動作フローチャートを第４図に示す。

ソフトウェアのリリース要求を受けるとリリースサーバ
はリリースされるソフトウェアを構成するファイルが既
に存在しているかを調べる（ステップ４−１）。存在し
ている場合にはファイルのリリース要求者とメインテナ
ーの項目を比較する（ステップ４−２）。比較の結果、
ファイルのメインテナーとリリース要求者とが一致した
場合にはソフトウェアのリリース処理を行ない（ステッ
プ４−４）、リリース手続を終了する。ファイルのメイ
ンテナーとリリース要求者とが一致しなかった場合、リ
リース処理を保留し該当ファイルのメインテナーなど関
係者に電子メールを用いて新しいパルジョンのソフトウ
ェアができたことを通知する（ステップ４−３）。

次に、新規リリース要求者のソフトウェアをリリースす
るかを元のメインテナーに確認しくステップ４−５）、
リリースするならば通常のソフトウェアと同様にリリー
ス処理を行う（ステップ４−６）。

このソフトウェアのメインテナーを新規リリース要求者
に変更するかどうかを元のメインテナーに確認しくステ
ップ４−７）、変更するならばリリースマツプのメイン
テナーの項を新規リリース要求者に変更する（ステップ
４−８）。これらの処理が終了するとリリース手続が終
了する。なおステップ４５においてリリースしない場合
にはソフトウェア名を変更して（ステップ４−９）、最
初からやり直す。

〔発明の効果〕

以上に説明したように、本発明によって、従来では手間
の掛かったソフトウェア研究・開発環境の維持を半自動
的に行うことができ、ソフトウェア研究・開発の効率を
向上させることができる。

またソフトウェアの変更が誰にでもできるようになるう
え、変更はそのメインテナに連絡が届くため、無制限な
ソフトウェアの書換えを防ぐことができ、ソフトウェア
を保守する手間を省くこ止ができるばかりでなくソフト
ウェアの安全性を高めることができる。

さらに、ソフトウェアの改良などが、リリースされてい
るソフトウェアに反映されやすいため、ソフトウェアの
品質の向上に役立つ。

【図面の簡単な説明】

第１図は本発明の実施例におけるリリースサーバの構成
図、第２図は本発明の実施例を示すブロック図、第３図
は実施例において使用するリリースマツプ、第４図はソ
フトウェアのリリース要求を受けた時のリリースサーバ
の動作フローチャートである。 １−１：制御装置　　　　１−２：記憶装置１−３＝通
信装置　　　　１−４：　Ｌ　Ａ　Ｎ１−５°リリース
サーバ ２−１ａ、　２−１ｂ、　２−１ｃ：　Ｌ　Ａ　Ｎ２−
２：ネットワーク間通信網 ２−３ａ、　２−３ｂ、　２−３ｃ：ファイルサーバ２
−４ａ、　２−４ｂ、　２−４ｃ：リリースサーバ０１
、０２．　Ｄ３ニドメイン 第１図 第２図 特許出願人　富士ゼロックス株式会社 代　　理　　人　　　　　小　　堀　　　益第３図 第４図

Claims (1)

1. 【特許請求の範囲】 １、ソフトウェアを保存しておくためのファイルサーバ
   を有し、そのコピーを別の地区のファイルサーバに持つ
   システムにおいて、各地区にリリースサーバを設け、各
   リリースサーバはファイル名、ディレクトリ、メインテ
   ナー、アクセスリスト等の情報を表したリリースマップ
   を持ち、このリリースマップを基に各リリースサーバが
   互いにリリースマップの比較をすることによって互いの
   ファイルサーバの内容を一致させるシステムにおいて、 ファイルの更新要求がなされたときに、リリースマップ
   のメインテナーの項と更新要求者とを比較し、異なる場
   合にはこのことをメインテナーと更新要求者の両者に確
   認をとってからファイルの更新を行うことにより、ソフ
   トウェアの共同研究、開発環境の統一性を保つファイル
   管理方式。