JPH0652031A - 多局分散型ファイル・バージョン管理方法 - Google Patents

Abstract

(57)【要約】 【目的】 多局間の共同作業によってソフトウェアを開
発する場合にファイル変更情報の交換によって生ずる通
信トラヒックを減少させると共に、全局のバージョン管
理の統一化を図り、ソフトウェアの生産性を向上させ
る。 【構成】 支局１０１，１０３においてファイルの変
更、削除等の編集作業を行い、一定期間経過後に最新の
ファイル１０５，１０７とその履歴とをセンタ局１０９
に送信する。センタ局１０９ではファイル１０５，１０
７を照合して、ファイル相互間に矛盾が無いか否かを確
認し、矛盾があれば該当する支局に矛盾発生のメッセイ
ジを送信する。このメッセイジを受けた支局は矛盾を生
じたファイルの再編集を行いセンタ局１０９に再送す
る。センタ局１０９は支局から送信されたファイルに矛
盾が無いと判断したときに、各支局から送られてきたフ
ァイルの履歴に基づいて、ファイル群１１１にバージョ
ンナンバ１１３を付し、各支局１０１，１０３に送信す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ファイルを多局間に渡
って管理する多局分散型ファイル・バージョン管理方法
に関する。

【０００２】

【従来の技術】一般に複数の開発者でソフトウェアを開
発するには１つのマシンに対して複数の開発者がそれぞ
れワークスペースを確保し、各自が自分の担当するファ
イルやディレクトリを編集しながら開発を進めるという
方式を取っている。この方式は、例えば文献Ｐ．Ｄ．Ｓ
ｔａｌｌｍｅｎ「ＦｒｅｅＳｏｆｔｗａｒｅの世界一Ｃ
ＶＳ」ＵＮＩＸ ＭＡＧＡＺＩＮＥ１９９０．１２．ｐ
ｐ７９−９０に詳しく示されている。

【０００３】ところが大規模なソフトウェアを開発をす
る場合には複数のマシンによる多局間の共同作業を行う
必要がある。この場合開発対象になっている同一ファイ
ル群は各局の開発者によって絶えずバージョンアップが
繰り返されている状態にあり、ファイル群全体の整合性
を保つために各局間で情報の交換を行う必要がある。そ
こで、従来はバージョンアップが発生する度にバージョ
ンアップを行った局から他の全ての局に新しいバージョ
ンのファイルを配布するという方式をとっていた。

【０００４】また、バージョン管理は変更したファイル
が各局に送られてくると各局で独自にバージョンナンバ
を付すことによって行っていた。

【発明が解決しようとする課題】

【０００５】上記のような従来の多局間ファイル・バー
ジョン管理方法では、バージョンアップが発生する度に
開発を行った局から他の全ての局に対して新しいバージ
ョンのファイルを配布しなければならず、通信トラヒッ
クが増加するという問題点があった。

【０００６】また、バージョン管理に関しては、各局が
他局で変更されたファイルに対して独自にバージョンナ
ンバを付すという方法を採っていたため、各局が同一フ
ァイルを異なるバージョンナンバで管理することにな
り、ソフトウェア開発過程における各局間の情報交換が
スムースに行えずソフトウェアの生産性が上がらないと
いう問題点もあった。

【０００７】本発明はかかる課題を解決するためになさ
れたものであり、多局間の共同作業によってソフトウェ
アを開発する場合にファイル変更情報の交換によって生
ずる通信トラヒックを減少させると共に、全局のバージ
ョン管理の統一化を図り、ソフトウェアの生産性を向上
させることを目的としている。

【０００８】

【課題を解決するための手段】本発明にかかる多局分散
型ファイル・バージョン管理方法は、各支局において前
記同一ファイル群から所望のファイルを読み出して、該
ファイルの内容の変更、削除等のファイル編集を行い、
該ファイル編集によって変更、削除等されたファイルの
履歴を記録しておく工程と、前記ファイル編集によって
一定の期間内に編集された最新の編集ファイル及び該編
集ファイルの該一定の期間内の履歴を記録した履歴ファ
イルをセンタ局に送信する工程と、各支局からセンタ局
に送信された編集ファイルを照合して、各編集ファイル
相互間の矛盾の有無を判断し、矛盾がある場合にはその
旨のメッセイジを該当する支局に送信する工程と、前記
メッセイジを受けた支局において、前記矛盾を生じた編
集ファイルの矛盾を解消し、矛盾を生じない編集ファイ
ルをセンタ局に再送する工程と、センタ局において、各
編集ファイル相互間に矛盾が無いと判断したとき、その
ときの編集ファイルに前記履歴ファイルに基づいて、編
集ファイル全体に統一のとれたバージョンナンバを付す
工程と、該バージョンナンバを付す工程によってバージ
ョンナンバが付された全ファイルを各支局に送信する工
程とを有することを特徴とするものである。

【０００９】

【作用】一定の期間内に新たに編集された編集ファイル
をセンタ局に送信することによってファイルの変更があ
る度に各支局に変更があった編集ファイルを送信する必
要がなくなる。各支局からセンタ局に送信された複数の
編集ファイルを照合して編集ファイル相互間の矛盾を検
出し、矛盾が解消された後に編集ファイル全体に統一の
とれたバージョンナンバを付し、これらの編集ファイル
を各支局に送信することによって、全局が同一のバージ
ョンナンバが付された同一のファイル群を所有すること
ができる。

【００１０】

【実施例】

実施例１．図１は本発明の一実施例の構成及び動作を概
念的に示す概念図である。まず図１に基づいて本実施例
の構成及び動作を概説する。図において、１０１，１０
３はソフトウェア開発の目的に合わせてファイルの変
更、削除等の編集作業を行う支局、１０５，１０７はそ
れぞれ支局１０１，１０３で一定期間に変更、削除等が
行われた最新のファイルである。１０９はセンタ局であ
り、センタ局１０９は支局１０１，１０３から送られて
きたファイル１０５，１０７を照合し、各ファイル間に
矛盾がないかどうかを確認し、矛盾があれば矛盾を生じ
たファイルを送信した局に矛盾発生のメッセイジを送信
する。このメッセイジを受けた支局は矛盾を生じたファ
イルの再編集を行いセンタ局１０９に再送する。センタ
局１０９は支局から送信されたファイルに矛盾が無いと
判断したときに、各支局から送られてきたファイルの履
歴に基づいて、ファイル１０５，１０７にバージョンナ
ンバ１１３を付し、各支局１０１，１０３に送信する。
支局１０１，１０３ではセンタ局１０９から送付された
ファイル１０５，１０７を受け取ると、旧ファイルをこ
のセンタ局から受け取ったファイルに書き換え、この書
き換えた新しいファイルに基づいて開発作業を続行す
る。

【００１１】次ぎに、上記の支局及びセンタ局の構成及
び動作について詳述する。図２は図１に示した本発明の
一実施例の構成の一部である支局の構成を示す部分構成
図である。図において、１はセンタ局から送信されるフ
ァイルを受信する受信手段、３は受信手段１が受信した
ファイルを一時的に格納する第１の記憶手段、５は開発
の対象となるソフトウェアのファイルやディレクトリを
格納しておく第２の記憶手段である。７は第１の記憶手
段３又は第２の記憶手段５に格納されているファイルを
読み出す読出手段、９は新たなファイル及びディレクト
リの内容を第２の記憶手段に書き込む書込手段である。
１１は読出手段７が読み出したファイルの内容を開発の
目的に合わせて書き換えたり、削除したりする編集手段
である。１５はファイル履歴管理手段であり、ファイル
履歴管理手段１５は開発の対象となっているファイルの
開発過程における変化、例えば新規作成、変更又は削除
の履歴を記録しておく。

【００１２】１３は予め定められた一定期間内に変更、
削除等によって新たに編集された最新のファイルを送信
用ファイルとしてまとめる変更ファイルまとめ手段であ
り、変更ファイルまとめ手段１３は最新のファイルと変
更の履歴が記録されたファイルを一組のファイルとして
編集する。１７は変更ファイルまとめ手段１３がまとめ
た一群のファイルをセンタ局に送信する送信手段であ
る。１９は入力手段であり、作業者は入力手段１９によ
って読出手段７にファイルの読み出し指示を与え、書込
手段９に書き込み指示を与え、さらに送信手段１７にフ
ァイルの送信指示を与える。また、作業者は入力手段１
９によって編集手段１１に所定の指示を与えることによ
ってワークスペースに読み出されたファイルの内容の変
更、削除等のソフトウェア開発作業を行う。

【００１３】図３は支局におけるソフトウェア開発時に
おける動作処理のフローチャートである。図２及び図３
に基づいて各支局におけるソフトウェア開発時の動作処
理を説明する。入力手段１９からの指示によって読出手
段７が第２の記憶手段５に格納されている開発の対象と
なっている一群のファイルの中から必要なファイルをワ
ークスペースに読み出す（ステップ２１）。作業者はソ
フトウェア開発の目的に合わせてワークスペイスに読み
出されたファイルの変更、削除等のファイル編集作業を
行う（ステップ２３）。編集作業が終了すると、ファイ
ル履歴管理手段１５が変更されたファイルの履歴が判る
ようにバージョンナンバを付与する（ステップ２５）。
このとき、ある一定の期間に同一ファイルに複数回の変
更が加えられた場合は変更回数が判るようにバージョン
ナンバを付与するようにする。例えば、更新前のファイ
ルのバージョンナンバがＶｅｒ１．０であり、変更回数
が３回あった場合は変更の度にＶｅｒ１．１、Ｖｅｒ
１．２、Ｖｅｒ１．３とバージョンナンバを更新し、こ
の履歴が判るように記録しておく。

【００１４】新しいバージョンナンバが付されたファイ
ルは書込手段９によって旧ファイルの内容を書き換える
ことによって第２の記憶手段に格納される（ステップ２
７）。なお、編集作業の内容がファイル全体の削除の場
合にはそのファイルが削除された旨の履歴を残してお
く。

【００１５】以上の処理を繰り返し、予め設定した指定
期間が満了したかどうかを判断して（ステップ２９）、
指定期間が満了した場合には指定期間中に新規作成、変
更又は削除ファイルがあるかどうかを判断する（ステッ
プ３１）。このときの判断方法としては、第２の記憶手
段に格納されているファイルの履歴を記録したファイル
を読み出して、指定期間内にバージョンナンバの変更又
はファイルの削除があるか否かで判断する。判断の結
果、変更ファイルが在るときは読出手段７によって、こ
れらの変更ファイル及び変更の履歴が記録されたファイ
ルを第２の記憶手段５から読み出して、これらを変更フ
ァイルまとめ手段１３によって送信用の一群のファイル
として編集する（ステップ３３）。変更ファイルまとめ
手段１３によって編集された一群のファイルは、送信手
段１７によってセンタ局に送信される（ステップ３
５）。

【００１６】図４はセンタ局から送信されたファイルを
受信した場合の支局における動作処理を示したフローチ
ャートである。図２及び図４に基づいて各支局における
ファイル受信時の動作処理を説明する。センタ局から送
信されてきたファイルは、受信手段１によって受信さ
れ、第１の記憶手段３に一旦格納される（ステップ４
１）。第１の記憶手段３に格納されたファイルは、読出
手段７によって順次読み出され（ステップ４３）、第２
の記憶手段５に格納されている同一名称のファイルの内
容を書込手段９によって書き換えることによって第２の
記憶手段に格納される（ステップ４５）。以上の動作を
繰り返し、第１の記憶手段３に格納された全てのファイ
ルの読み出しが完了したことを確認して（ステップ４
７）、処理が終了する。尚、センタ局から送信されたフ
ァイルが第２の記憶手段に格納された後はこのファイル
に基づいて新たな開発作業が続行される。

【００１７】次ぎに、センタ局の構成及び動作処理につ
いて説明する。図５は図１に示した本発明の一実施例の
構成の一部であるセンタ局の構成を示す部分構成図であ
る。図において、５１は各支局から送信される変更ファ
イルのデータを受信する受信手段、５３は受信手段５１
が受信した変更ファイルのデータを一時的に格納する第
１の記憶手段である。５５は第１の記憶手段５３又は後
述する第２の記憶手段に格納されているファイルを読み
出す読出手段である。

【００１８】５７は読出手段５５によって第１の記憶手
段５３から読み出された各支局で作製されたファイル相
互間に矛盾が無いかどうかを点検し、矛盾がある場合に
はその旨のメッセイジを出力する矛盾検出手段である。
ここでいう矛盾とは、例えば同一ファイルの同一箇所が
異なる人によって書き換えられている場合、第１支局の
Ａさんが削除したファイルと同一のファイルに第２支局
のＢさんが書き換えを行っている場合、今までと同じフ
ァイル名が同じディレクトリ内に作られている場合等が
ある。矛盾検出手段５７によって出力された矛盾発生の
旨のメッセイジは後述する送信手段６５によって矛盾の
原因となったファイルを送信した支局にを送信される。

【００１９】５９は矛盾検出手段５７によってファイル
相互間に矛盾が無いことが確認され、又は矛盾が解消さ
れた各ファイルに改めてバージョンナンバを付す管理番
号付与手段である。管理番号付与手段５９におけるバー
ジョンナンバの付しかたは、各支局から送信されてきた
ファイルの履歴を参照し、同一ファイルに対して全局で
何回バージョンアップが行われたかという基準で行う。
例えば、各支局がＡファイルのＶｅｒ１．０を持ってい
た場合に、第１支局と第２支局が共にＡファイルの内容
の変更（同一ファイルの別の箇所の変更）を１回行いそ
れぞれ各支局で独自に、Ｖｅｒ１．１というバージョン
ナンバを付してセンタ局に送信した場合は、Ａファイル
は全局では２回のバージョンアップが行われているので
このＡファイルのバージョンナンバはＶｅｒ１．２とす
る。６１は管理番号付与手段５９によって新たな管理番
号が付与されたファイルを第２の記憶手段６３に書き込
む書込手段である。

【００２０】６５はある一定期間に変更されたファイル
を各支局に送信する送信手段である。６７は入力手段で
あり、センタ局の作業者は入力手段６７によって読出手
段５５にファイルの読み出し指示を与え、送信手段６５
にファイルの送信指示を与える。

【００２１】図６はセンタ局における動作処理のフロー
チャートである。図５及び図６に基づいてセンタ局にお
ける動作処理を説明する。各支局から送信されて来るフ
ァイルは受信手段５１によって受信され、第１の記憶手
段５３に格納される（ステップ８１）。各支局からの変
更ファイルの送信が完了したことを確認した後、読出手
段５５によって第１の記憶手段５３に格納されているフ
ァイルを読み出し、矛盾検出手段５７によって各支局か
ら送信されたファイル間の矛盾の有無を確認する（ステ
ップ８３）。

【００２２】矛盾の有無判断において（ステップ８
５）、各ファイル間に矛盾が有ると判断した場合は矛盾
検出手段５７が矛盾発生の旨のメッセイジを出力し、送
信手段６５がこのメッセイジを矛盾の原因となったファ
イルを送信した支局に送信する（ステップ８６）。この
メッセイジを受けた支局はファイルの変更、削除等によ
って矛盾を解消する（ステップ８７）。矛盾が無かった
場合又は矛盾を解消した場合には読み出されたファイル
は管理番号付与手段５９によって新たな管理番号が付与
され（ステップ８８）、書込手段６１によって第２の記
憶手段に書き込まれる（ステップ８９）。全ての変更フ
ァイルの書き込みが終了すると、読出手段５５によって
今回新たに書き込まれたファイル及び管理番号を全て読
み出して（ステップ９１）、送信手段６５によって各支
局に送信する（ステップ９３）。

【００２３】

【発明の効果】本発明においては、一定の期間に新たに
編集された最新の編集ファイルをセンタ局に送信するよ
うにしたので、ファイルの変更がある度に各支局に変更
されたファイルを送信する必要がなくなり通信トラヒッ
クを軽減することができる。

【００２４】また、各支局からセンタ局に送信された複
数の編集ファイルは、それぞれセンタ局で矛盾の検出が
行われ、各編集ファイル間の矛盾が解消された後に、編
集ファイル全体に統一のとれたバージョンナンバを付し
て再度各支局に送信するようにしたので、全局が同一の
バージョンナンバが付された同一のファイル群を所有す
ることができ、ソフトウェアの開発環境が向上しソフト
ウェア生産性が向上する。

【図面の簡単な説明】

【図１】本発明の一実施例の構成及び動作を概念的に示
す概念図である。

【図２】図１に示した本発明の一実施例の構成の一部で
ある支局の構成を示す部分構成図である。

【図３】支局におけるソフトウェア開発時における動作
処理のフローチャートである。

【図４】センタ局から送信されたファイルを受信した場
合の支局における動作処理を示したフローチャートであ
る。

【図５】図１に示した本発明の一実施例の構成の一部で
あるセンタ局の構成を示す部分構成図である。

【図６】センタ局における処理のフローチャートであ
る。

【符号の説明】

１０１，１０３ 各支局 １０５，１０７ 編集ファイル １０９ センタ局 １１３ バージョンナンバ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 多局間で同一ファイル群を対象にソフト
   ウェアの開発をする場合の前記同一ファイル群のバージ
   ョン管理方法において、 各支局において前記同一ファイル群から所望のファイル
   を読み出して、該ファイルの内容の変更、削除等のファ
   イル編集を行い、該ファイル編集によって変更、削除等
   されたファイルの履歴を記録しておく工程と、 前記ファイル編集によって一定の期間内に編集された最
   新の編集ファイル及び該編集ファイルの該一定の期間内
   の履歴を記録した履歴ファイルをセンタ局に送信する工
   程と、 各支局からセンタ局に送信された編集ファイルを照合し
   て、各編集ファイル相互間の矛盾の有無を判断し、矛盾
   がある場合にはその旨のメッセイジを該当する支局に送
   信する工程と、 前記メッセイジを受けた支局において、前記矛盾を生じ
   た編集ファイルの矛盾を解消し、矛盾を生じない編集フ
   ァイルをセンタ局に再送する工程と、 センタ局において、各編集ファイル相互間に矛盾が無い
   と判断したとき、そのときの編集ファイルに前記履歴フ
   ァイルに基づいて、編集ファイル全体に統一のとれたバ
   ージョンナンバを付す工程と、 該バージョンナンバを付す工程によってバージョンナン
   バが付された全ファイルを各支局に送信する工程とを有
   することを特徴とする多局分散型ファイル・バージョン
   管理方法。