如何编写一个简单的版本控制系统？

php algorithm data-structures sql code-organization

2022-08-30 19:21:07

我想做一个简单的版本控制系统，但我不知道如何构建我的数据和代码。

下面是一个简短示例：

用户登录
上传文件时，用户有两个选项：
- 提交新文件
- 提交文件的新版本

用户应该能够看到树。（不同版本）树最多只能有 2 个级别：

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

还有2种类型的文件，最终（这是最新批准的版本）和草稿版本（最新上传的文件），该文件将物理存储在服务器上。每个文件由一个（或多个）用户拥有，并且只有一个组。

编辑：组表示一组文档，文档一次只能由一个组拥有。用户不依赖于组。

开始编辑：

这是我所做的，但它并不是真的有效！

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

id_draft | id_file | version | date

但这很难管理，很难扩展。我认为这是因为组参数...

结束编辑

所以问题是：

如何对数据库进行架构化？
什么样的信息应该有用来版本化这项工作？
文件夹，文件的结构是什么？
做这种工作，你有什么样的提示，提示？

（应用程序是用PHP和Zend框架开发的，数据库应该是mysql或postgresql）

答案 1

看在上帝的份上，不要。你真的不想走这条路。

停下来想一想更大的图景。你想保留文档的早期版本，这意味着在某些时候，有人会想要看到一些早期版本，对吧？然后他们会问，“版本3和版本7有什么区别”？然后他们会说，“我想回滚到版本3，但保留我在版本5中所做的一些更改，嗯，好吗？”

版本控制并非易事，也没有必要重新发明轮子 - 那里有很多可行的版本控制系统，其中一些甚至是免费的。

从长远来看，学习其中一个系统的API，并编写一个Web前端，为用户提供他们正在寻找的功能子集（现在）会容易得多。

你不会为你的用户编写文本编辑器，对吧？

答案 2

你可能会从那里获得灵感。

关于您的评论：

至于数据库结构，你可以试试这种结构（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`)
);

文档是一个逻辑容器，修订包含指向文件的实际链接。每当有人更新新文件时，请在每个表中创建一个条目，“修订版”中的条目包含指向“文档”中插入的条目的链接。

表格M2M_UserRev允许将多个用户与文档的每个修订版本相关联。

更新文档时，仅在“修订”中插入，并带有指向相应文档的链接。若要知道要链接到哪个文档，可以使用命名约定，或要求用户选择正确的文档。

对于文件的文件系统架构，这真的无关紧要。我只是在将文件存储在服务器上之前将其重命名为唯一文件，并将用户名保留在数据库中。只需将重命名的文件存储在任意位置的文件夹中，并将其路径保留在数据库中即可。这样，您就可以在用户要求时如何重命名它。如果您确定用户给出的原始名称是唯一的，您也可以保留它，但我不会太依赖它。您可能很快就会看到两个不同的修订版具有相同的名称，一个在文件系统上覆盖了另一个修订版。