22

単純なバージョン管理システムを作成したいのですが、データとコードを構造化する方法についてのアイデアがありません。

以下に短い例を示します。

  1. ユーザーのログイン
  2. ファイルをアップロードするとき、ユーザーには 2 つのオプションがあります。
    • 新しいファイルを提出する
    • ファイルの新しいバージョンを送信する

ユーザーはツリーを表示できる必要があります。(異なるバージョン) ツリーは最大 2 レベルまでです。

|
|--File_A_0
 \--File_A_1
 \--File_A_2
 \--File_A_3
 \--File_A_4

ファイルには、最終バージョン (最新の承認済みバージョン) とドラフト バージョン (最新のアップロード ファイル) の 2 種類があります。ファイルは物理的にサーバーに保存されます。各ファイルは、ユーザー (または複数) と 1 つのグループのみが所有しています。

編集:グループはドキュメントのグループを表し、ドキュメントは一度に 1 つのグループのみが所有できます。ユーザーはグループに依存しません。

編集を開始:

これが私がやったことですが、実際には効率的ではありません!

id_article | relative_group_id | id_group | title | submited | date | abstract | reference | draft_version | count | status

id_draft | id_file | version | date

しかし、管理すること、拡張することは困難です。グループパラメータが原因だと思います...

編集を終了

質問は次のとおりです。

  • データベースをスキーマ化するにはどうすればよいですか?
  • この作業のバージョン管理に役立つ情報は何ですか?
  • フォルダ、ファイルの構造はどのようなものですか?
  • この種の作業を行うには、どのようなヒント、ヒントが必要ですか?

(アプリケーションは PHP と Zend Framework で開発され、データベースは mysql または postgresql である必要があります)

4

13 に答える 13

50

神のために、しないでください。あなたは本当にこの道を行きたくない。

少し立ち止まって、全体像について考えてみてください。ドキュメントの以前のバージョンを保持したいということは、ある時点で、誰かがそれらの以前のバージョンのいくつかを見たいと思うということですよね? そして、彼らは「バージョン 3 とバージョン 7 の違いは何ですか?」と尋ねます。そして、彼らは「バージョン 3 にロールバックしたいが、バージョン 5 に加えた変更の一部を保持したい」と言うでしょう。

バージョン管理は簡単ではなく、一からやり直す必要はありません。実行可能なバージョン管理システムはたくさんあり、中には無料のものもあります。

長期的には、これらのシステムのいずれかの API を学習し、ユーザーが探している機能のサブセットを提供する Web フロントエンドをコーディングする方がはるかに簡単です (現在)。

ユーザーのためにテキスト エディターをコーディングすることはありませんよね?

于 2009-06-15T18:53:08.907 に答える
18

そこからインスピレーションを得るかもしれません。


あなたのコメントについて:

データベース構造に関しては、次のような構造 (MySQL sql) を試すことができます。

CREATE TABLE `Users` (
       `UserID` INT NOT NULL AUTO_INCREMENT
     , `UserName` CHAR(50) NOT NULL
     , `UserLogin` CHAR(20) NOT NULL
     , PRIMARY KEY (`UserID`)
);

CREATE TABLE `Groups` (
       `GroupID` INT NOT NULL AUTO_INCREMENT
     , `GroupName` CHAR(20) NOT NULL
     , PRIMARY KEY (`GroupID`)
);

CREATE TABLE `Documents` (
       `DocID` INT NOT NULL AUTO_INCREMENT
     , `GroupID` INT NOT NULL
     , `DocName` CHAR(50) NOT NULL
     , `DocDateCreated` DATETIME NOT NULL
     , PRIMARY KEY (`DocID`)
     , INDEX (`GroupID`)
     , CONSTRAINT `FK_Documents_1` FOREIGN KEY (`GroupID`)
                  REFERENCES `Groups` (`GroupID`)
);

CREATE TABLE `Revisions` (
       `RevID` INT NOT NULL AUTO_INCREMENT
     , `DocID` INT
     , `RevUserFileName` CHAR(30) NOT NULL
     , `RevServerFilePath` CHAR(255) NOT NULL
     , `RevDateUpload` DATETIME NOT NULL
     , `RevAccepted` BOOLEAN NOT NULL
     , PRIMARY KEY (`RevID`)
     , INDEX (`DocID`)
     , CONSTRAINT `FK_Revisions_1` FOREIGN KEY (`DocID`)
                  REFERENCES `Documents` (`DocID`)
);

CREATE TABLE `M2M_UserRev` (
       `UserID` INT NOT NULL
     , `RevID` INT NOT NULL
     , INDEX (`UserID`)
     , CONSTRAINT `FK_M2M_UserRev_1` FOREIGN KEY (`UserID`)
                  REFERENCES `Users` (`UserID`)
     , INDEX (`RevID`)
     , CONSTRAINT `FK_M2M_UserRev_2` FOREIGN KEY (`RevID`)
                  REFERENCES `Revisions` (`RevID`)
);

Documents は論理的なコンテナーであり、Revisions にはファイルへの実際のリンクが含まれています。人が新しいファイルを更新するたびに、これらのテーブルのそれぞれにエントリを作成します。ドキュメントに挿入されたものへのリンクを含むリビジョンのエントリです。

テーブル M2M_UserRev を使用すると、ドキュメントの各リビジョンに複数のユーザーを関連付けることができます。

ドキュメントを更新するときは、対応するドキュメントへのリンクとともに、リビジョンにのみ挿入します。どのドキュメントにリンクするかを知るには、命名規則を使用するか、ユーザーに適切なドキュメントを選択するように依頼します。

ファイルのファイル システム アーキテクチャについては、実際には問題になりません。サーバーに保存する前に、ファイルの名前を一意の名前に変更し、ユーザーファイル名をデータベースに保持します。名前を変更したファイルを任意のフォルダに保存し、そのパスをデータベースに保持するだけです。このようにして、ユーザーが要求したときに名前を変更する方法を知っています。一意であることが確実な場合は、ユーザーが付けた元の名前を保持することもできますが、あまり信頼しません。同じ名前の 2 つの異なるリビジョンがすぐに表示され、ファイル システム上で一方が他方を上書きすることがあります。

于 2009-06-09T21:45:34.417 に答える
13

データベース スキーマ


非常にシンプルにするために、次のデータベース設計を選択します。「ファイル」(ファイルシステムファイルと同じ)の概念を「ドキュメント」(ドキュメントの一般的なグループ)の概念から分離しています。

ユーザーエンティティ:

  • ユーザーID
  • ユーザー名

グループエンティティ:

  • グループ ID
  • グループ名

ファイルエンティティ:

  • fileId (シーケンス)
  • fileName (ユーザーがファイルに付ける名前)
  • ファイルシステムフルパス
  • アップロード時間
  • uploaderId (アップローダー ユーザーの ID)
  • 所有者グループ ID

ドキュメントエンティティ:

  • ドキュメント ID
  • 親ドキュメント ID
  • ファイル ID
  • バージョンナンバー
  • 作成時間
  • 承認済み

新しいファイルがアップロードされるたびに、「ファイル」レコードと新しい「ドキュメント」が作成されます。そのファイルが初めてアップロードされる場合、そのドキュメントのparentDocumentIdはNULLになります。それ以外の場合、新しいドキュメント レコードは最初のバージョンを指します。

「isApproved」フィールド (ブール値) は、ドキュメントがドラフトまたは承認されたリビジョンであることを処理します。
バージョン番号またはアップロード時間の降順に並べるだけで、ドキュメントの最新のドラフトを取得できます。

ヒント


問題の説明方法から、データベース スキーマの設計に移る前に、これらの側面をよりよく分析する必要があります。

  • 「グループ」エンティティの役割はどれですか?
  • グループ/ユーザー/ファイルはどのように関連していますか?
  • 異なるグループの 2 人のユーザーが同じドキュメントをアップロードしようとするとどうなりますか?
  • フォルダが必要ですか?(おそらくそうするでしょう。私の解決策はまだ有効で、「ドキュメント」エンティティに「フォルダ」または「ドキュメント」のタイプを与えます)

お役に立てれば。

于 2009-06-13T11:03:16.530 に答える
9

独自のバージョン管理ソリューションよりも、既存のバージョン管理ソリューションの方がうまく機能する可能性はありますか? Subversion は、あなたが望むことのほとんどを行うことができます。

于 2009-06-13T15:57:15.277 に答える
6

MySQL などの従来のリレーショナル データベースで豊富なデータ構造を作成することは、多くの場合困難であり、それを実現するためのはるかに優れた方法があります。階層を持つパス ベースのデータ構造を扱う場合、JSON などのデータ シリアル化形式を使用して特定のファイル、ディレクトリ、またはリポジトリ全体に関する情報を格納するフラット ファイル ベースのシステムを作成するのが好きです。

このようにして、現在利用可能なツールを使用して構造を簡単にナビゲートおよび操作し、構造を簡単に読み取り、編集し、理解することができます。XML はこれにも適しています。XML は JSON よりも少し冗長ですが、読みやすく、メッセージングやその他の XML ベースのシステムにも適しています。

簡単な例。ディレクトリと 3 つのファイルを持つリポジトリがあるとします。正面から見ると次のようになります。

/repo
  /folder
    code.php
  file.txt
  image.jpg

OS から隠されている JSON ファイルを含むメタデータ フォルダーを、各ディレクトリのルートに配置して、そのディレクトリの内容を記述できます。これは、JSON の代わりにカスタム言語を使用することを除いて、従来のバージョン管理システムがどのように機能するかです。

/repo
  */.folderdata*
  /code
    */.folderdata*
    code.php
  file.txt
  image.jpg

.folderdataフォルダーには、フォルダーのデータを適切に整理するために使用できる独自の構造を含めることができます。次に、各.folderdataフォルダーを圧縮して、ディスク容量を節約できます。/code ディレクトリ内の.folderdataフォルダーを見ると、次のようになります。

*/.folderdata*
  /revisions
    code.php.r1
    code.php.r2
    code.php.r3
  folderstructure.json
  filerevisions.json

フォルダー構造は、ファイルとフォルダーが相互に関連しているフォルダーの構造を定義します。これは次のようになります。

{
  '.':        'code',
  '..':       'repo',
  'code.php': {
    'author_id': 11543,
    'author_name': 'Jamie Rumbelow',
    'file_hash': 'a26hb3vpq22'
    'access': 'public'
  }
}

これにより、そのファイルに関するメタデータの関連付け、信頼性と整合性のチェック、永続的なデータの保持、ファイル属性の指定など、さまざまなことが可能になります。その後、特定のリビジョンに関する情報を filerevisions.json ファイルに保持できます。

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

これは、ファイル バージョン管理システムの基本的な概要計画です。私はこのアイデアとそのしくみが気に入っています。過去に JSON を使用して、このような豊富なデータ構造に大きな効果をもたらしました。この種のデータは、MySQL などのリレーショナル データベースには適していません。リビジョンやファイルが増えると、データベースはどんどん大きくなります。このようにして、複数のファイルにわたってリビジョンをずらしたり、すべてのバックアップを保持したり、作成したりできます。インターフェイスやプラットフォームなど全体で永続的なデータがあることを確認してください。

これがあなたにいくらかの洞察を与えてくれることを願っており、うまくいけば、コミュニティにも思考の糧を提供するでしょう!

于 2009-06-15T11:22:58.830 に答える
2

私は最近、いくつかの静的データエンティティ用の単純なバージョン管理システムを構築しました。要件は、「アクティブ」バージョンと0または1の「保留中」バージョンを持つことでした。

結局、私のバージョン管理されたエンティティには、バージョン管理に関連する次の属性がありました。

VersionNumber(int / long)ActiveVersionFlag(ブール値)

どこ:-

  • ActiveVersionFlag='Y'になることができるエンティティは1つだけです
  • 1つのエンティティのみがバージョン番号>「アクティブ」バージョン(つまり「保留中」バージョン)になることができます

私が許可した操作の種類は

現在のバージョンのクローンを作成します。

  • すでにバージョンが存在する場合は失敗>「アクティブ」バージョンのバージョン番号
  • すべてのデータを新しいバージョンにコピーします
  • バージョン番号を1つインクリメントします

保留中のバージョンをアクティブ化

  • 指定されたバージョンが「アクティブ」バージョン+1でない場合は失敗します
  • 「アクティブ」バージョンを見つけて、そのActiveVersionFlagを「N」に設定します
  • 「保留中」バージョンのActiveVersionFlagを「Y」に設定します

保留中のバージョンを削除

  • 保留中のエンティティを削除します

これはかなり成功し、私のユーザーは常にクローンを作成してアクティブ化します:)

マイケル

于 2009-06-19T05:09:25.247 に答える
2

データベーススキーマの場合、ファイルとファイルバージョンの2つの情報セットが必要になる可能性があります。新しいファイルが保存されると、初期バージョンも作成されます。最新の承認済みバージョンは明示的に保存する必要がありますが、最新バージョンはバージョンテーブルから選択できます(ファイルに関連する最高のバージョンを見つけるか、作成時に保存する場合は最新の日付を選択します)。

files(id,name,approved_version)
file_versions(id,fileId)

ファイルバージョンは、ID(たとえば、「/ fileId/versionId」または「/fileId/ versionId_fileName」)を使用してサーバーに保存し、元の名前をデータベースに保存できます。

于 2009-06-09T23:51:24.787 に答える
1

eZ PublishKnowledgetreeなど、既存のコンテンツ管理システムから始めて、必要に応じて PHP と MySQL で実行します。これらのアプリケーションを迅速にテストするために、Bitnamiは、これらの迅速にインストールできる「スタック」も提供します (ステロイドの WAMP スタック)。

その後、これらのアプリケーションを組織のニーズに合わせて調整し、アップストリームの変更を最新の状態に保つことができます。

于 2009-06-17T15:54:06.510 に答える
1

前回の投稿の代わりに、階層構造が最適だと思われる場合は、フラット ファイル ストレージを使用し、Web サービスを介して API を公開することをお勧めします。

サーバーにはデータ ルート ディレクトリがあり、(ファイルの) グループをフォルダに格納し、各フォルダにルート メタデータ エントリを配置できます。(おそらくXML?)

次に、API にラップされた既存のリビジョン管理ツールを使用するか、独自のロールを作成して、フォルダ内のアイテムの下にあるリビジョン フォルダにファイルのリビジョンを保持します。リビジョンを確認し、ファイル I/O コマンドでファイル I/O を実行します。API を Web アプリケーションまたは他のクライアント アプリケーションに公開し、サーバーが XML ファイルを介してファイルのアクセス許可とユーザー マッピングを決定できるようにします。

サーバーを移行しますか? 圧縮してコピーします。クロスプラットフォーム?圧縮してコピーします。バックアップ?圧縮してコピーします。

たとえば、Mercurial DVCS で気に入っているのは、フラット ファイル バックエンドです。

もちろん、この小さな例では、.rev ファイルは、revisions.xml ファイルで定義された日付、時刻、圧縮などを持つことができます。これらのリビジョンの 1 つにアクセスする場合は、AccessFile() メソッドを公開します。サーバー アプリケーションは、revisions.xml を参照し、そのファイルを開く方法、アクセスが許可されているかどうかなどを決定します。

だからあなたは持っています

データ
| | + ルート
| | | | . メタデータ.xml
| | | | | |
| | | | + 改訂
| | | | | | . Revisionsdata.xml
| | | | | | . documenta.doc.00.rev
| | | | | | . documenta.doc.01.rev
| | | | | | . documentb.ppt.00.rev
| | | | | | . documentb.ppt.03.rev
| | | | |___
| | | | | |
| | | | . ドキュメンタ.doc
| | | | . 文書b.ppt
| | | | | |
| | | | + GROUP_A
| | | | | | . メタデータ.xml
| | | | | | | |
| | | | | | + 改訂
| | | | | | | | . Revisionsdata.xml
| | | | | | | | . documentc.doc.00.rev
| | | | | | | | . documentc.doc.01.rev
| | | | | | | | . documentd.ppt.00.rev
| | | | | | | | . documentd.ppt.03.rev
| | | | | | |___
| | | | | |
| | | | | | . ドキュメントc.doc
| | | | | | . 文書化.ppt
| | | | |___
| | | | | |
| | | | + GROUP_B
| | | | | | . メタデータ.xml
| | | | |___
| | | |
| | |___
| |
|___
于 2009-06-18T20:07:12.007 に答える
0

これはバージョン管理に最適なシステムを説明していると思います

http://tom.preston-werner.com/2009/05/19/the-git-parable.html

于 2009-07-06T09:36:58.233 に答える
0

ProjectPier (元はActiveCollab )を確認してください。これに似たシステムがあり、ソースを見ることができます。

于 2009-06-09T21:50:08.557 に答える
0

見た目ほど単純ではありません。これらのファイルを保存するストレージの影響については、Eric Sink によるこの記事をお読みください。

おそらく、ロードされているファイルの種類と、バージョン管理に適しているか (テキスト ファイルなど) という質問の方が適切でしょう。

于 2009-06-16T09:07:28.307 に答える
0

ファイルのアップロードは 1990 年までです =) Google Wave を見てください。「バージョン管理」フレームワークを中心にアプリケーション全体を構築するだけです。

于 2009-06-13T09:01:09.490 に答える