一种设计文件在线版本管理方法及装置

摘要

本申请公开了一种设计文件在线版本管理方法及装置。所述方法包括：当用户创建在线文件时，为所述在线文件创建文件版本仓库、HEAD指针和版本记录，所述HEAD指针用于指向某个分支，所述分支由同一工作空间的所有版本按照修改时间串连而成，所述文件工作空间指实际的文件内容，所述分支包括主分支和新分支，当只存在一个分支时，该分支称为主分支，所述新分支以所述主分支上的某个版本为起点；当文件被用户修改时，将修改完的文件版本作为最新版本提交到所述的版本仓库中，并更新所述版本记录；将所述新分支与所述主分支进行合并。所述装置包括：初始模块、新版本创建模块和合并模块。

说明书

技术领域

本申请涉及设计文件版本管理领域，特别是涉及设计文件在线版本管理的方法与装置。

背景技术

设计文件在线版本管理通常有以下两种方式：

一、每台电脑本地都有一个完整的本地仓库，对设计文件在线版本进行管理时，需要把本地文件的修改提交到本地仓库，在同一个局域网内，两台电脑互相进行访问，通过把各自的修改推送给对方进行协作。

这种方式的缺点在于：

1、文件的修改无法自动提交到版本库；

2、在本地仓库修改文件内容时，各成员无法进行实时协作；

3、推送版本仓库修改受到局域网的限制，各电脑须在同时处于同一局域网内。

二、每台电脑本地都有一个完整的本地仓库，对设计文件在线版本进行管理时，需要把本地文件的修改提交到本地仓库，再把本地仓库的修改提交到远程仓库，在远程仓库推送修改进行文件协作。

这种方式的缺点在于：

1、需要将文件从远程仓库下载到本地仓库，才能修改文件内容；

2、在本地仓库修改文件内容时，成员无法进行实时协作，文件修改完成后，需提交修改到本地仓库，再把本地仓库的修改提交到远程仓库；

3、远程仓库只能追踪到本地仓库提交修改的记录，无法追踪文件在本地仓库的修改记录。

发明内容

本申请的目的在于克服上述问题或者至少部分地解决或缓减解决上述问题。

根据本申请的一个方面，提供了一种设计文件在线版本管理方法，包括：

当用户创建在线文件时，为所述在线文件创建文件版本仓库、HEAD指针和版本记录，所述HEAD指针用于指向某个分支，所述分支由同一工作空间的所有版本按照修改时间串连而成，所述文件工作空间指实际的文件内容，所述分支包括主分支和新分支，当只存在一个分支时，该分支称为主分支，所述新分支以所述主分支上的某个版本为起点；

当文件被用户修改时，将修改完的文件版本作为最新版本提交到所述的版本仓库中，并更新所述版本记录；

将所述新分支与所述主分支进行合并。

在所述的将新分支与所述主分支进行合并之前，所述方法还包括：

由所述新分支向所述主分支提交合并申请；

判断所述主分支是否存在超前提交；

当所述主分支不存在超前提交时，所述主分支批准所述合并申请，所述超前提交指所述新分支创建后，所述主分支出现的提交；

当所述主分支存在超前提交时，对所述主分支的工作空间与所述新分支的工作空间相冲突的内容进行标记，并提示用户对所述主分支和/或所述新分支的工作空间进行修改。

将所述新分支与所述主分支进行合并包括：

将所述主分支的工作空间指所述向新分支的当前提交，并删除所述新分支，完成合并。

将所述新分支与所述主分支进行合并包括：

在所述主分支创建一个新的提交，并删除所述新分支，完成合并，所述新的提交的文件内容与所述新分支上最新提交的文件内容相同。

所述方法还包括：

根移动所述HEAD指针，使其指向要恢复到的分支，并创建新的分支，将所述HEAD指针切换到所述新的分支上，同时，更新所述在线文件的工作空间，完成在线文件版本的回退。

根据本申请的另一个方面，提供了一种设计文件在线版本管理装置，包括：

初始模块，其配置成当用户创建在线文件时，为所述在线文件创建文件版本仓库、HEAD指针和版本记录，所述HEAD指针用于指向某个分支，所述分支由同一工作空间的所有版本按照修改时间串连而成，所述文件工作空间指实际的文件内容，所述分支包括主分支和新分支，当只存在一个分支时，该分支称为主分支，所述新分支以所述主分支上的某个版本为起点；

新版本创建模块，当文件被用户修改时，将修改完的文件版本作为最新版本提交到所述的版本仓库中，并更新所述版本记录；和

合并模块，其配置成将所述新分支与所述主分支进行合并。

所述装置还包括：

申请模块，其配置成由所述新分支向所述主分支提交合并申请；

判断模块，其配置成判断所述主分支是否存在超前提交；

批准模块，其配置成当所述主分支不存在超前提交时，所述主分支批准所述合并申请，所述超前提交指所述新分支创建后，所述主分支出现的提交；

冲突解决模块，其配置成当所述主分支存在超前提交时，对所述主分支的工作空间与所述新分支的工作空间相冲突的内容进行标记，并提示用户对所述主分支和/或所述新分支的工作空间进行修改。

所述合并模块包括：

工作空间转移子模块，其配置成将所述主分支的工作空间指所述向新分支的当前提交，

第一删除子模块，其配置成删除所述新分支，完成合并。

所述合并模块包括：

新提交创建子模块，其配置成在所述主分支创建一个新的提交；

第二删除子模块，其配置成删除所述新分支，完成合并，所述新的提交的文件内容与所述新分支上最新提交的文件内容相同。

所述装置还包括：

回退模块，其配置成移动所述HEAD指针，使其指向要恢复到的分支，并创建新的分支，将所述HEAD指针切换到所述新的分支上，同时，更新所述在线文件的工作空间，完成在线文件版本的回退。

本申请的一种设计文件在线版本管理方法及装置，创新性的将分布式版本控制系统应用在在线文件，通过实时追踪在线文件提交的修改和推送修改到其他文件分支实现在线文件的版本管理以及团队实时协作，相比较于要把文件从远程库下载到本地库、把文件修改提交到本地库、再将本地库修改提交到远程库分支，本申请只需要考虑推送修改审批、完成合并即可。

根据下文结合附图对本申请的具体实施例的详细描述，本领域技术人员将会更加明了本申请的上述以及其他目的、优点和特征。

附图说明

后文将参照附图以示例性而非限制性的方式详细描述本申请的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：

图1是根据本申请一个实施例的一种设计文件在线版本管理方法的示意性流程图；

图2是根据本申请一个实施例的主分支的结构示意图；

图3是根据本申请一个实施例的在主分支上创建的新分支的结构示意图；

图4是根据本申请一个实施例的新分支中出现新提交时的结构示意图；

图5是根据本申请一个实施例的快速合并的原理示意图；

图6是根据本申请一个实施例的禁用快速合并的原理示意图；

图7是根据本申请一个实施例的合并时发生冲突的主分支与新分支的结构示意图；

图8是根据本申请一个实施例的解决冲突的原理示意图；

图9是根据本申请一个实施例的删除新分支的原理示意图；

图10是根据本申请一个实施例的版本回退的原理示意图；

图11是根据本申请一个实施例的另一种版本回退的原理示意图；

图12是根据本申请一个实施例的一种设计文件在线版本管理装置的结构示意图；

图13是根据本申请一个实施例的一种计算设备的结构示意图；

图14是根据本申请一个实施例的一种计算机可读存储介质的结构示意图。

具体实施方式

图1是根据本申请一个实施例的一种设计文件在线版本管理方法的示意性流程图。所述设计文件在线版本管理方法一般性地可包括：

步骤S1、当用户创建在线文件时，为所述在线文件创建文件版本仓库、HEAD指针和版本记录，所述HEAD指针用于指向某个分支，所述分支由同一工作空间的所有版本按照修改时间串连而成，所述文件工作空间指实际的文件内容，所述分支包括主分支和新分支，当只存在一个分支时，该分支称为主分支，所述新分支以所述主分支上的某个版本为起点；

步骤S2、当文件被用户修改时，将修改完的文件版本作为最新版本提交到所述的版本仓库中，并更新所述版本记录；

步骤S3、将所述新分支与所述主分支进行合并。

下面举例说明分支的创建、合并、以及删除的原理。

如图2所示的主分支(图2至图8中，空心圆表示实时提交，实心圆表示主动提交，文件内容只要发生修改就会实时提交，手动提交是对当前提交的修改做一个标记，需要用户手动添加)。版本仓库把提交的文件内容的修改串成一条时间线，这条时间线就是一个分支。当一个文件的版本仓库里只有一条时间线(即只有一个分支)时，这个分支就是主分支。每次有新版本提交，主分支的指针都会向前移动一步(分支的指针指向分支的最新提交)，随着修改的不断提交，主分支的线也越来越长，主分支的工作空间指向主分支上最新的提交版本。

用户可以以主分支的某个版本为基础创建新的分支，如图3所示，当创建新分支时，仓库空间就创建了一个新的工作空间。所述的新分支可以视为主分支的工作副本，创建新分支不会影响主分支的文件。新分支也称作子分支，在新分支中，可以浏览和编辑工作空间的内容，在新分支工作空间的修改和提交均针对所述新分支，每提交一次，新分支的指针往前移动一步，而主分支的指针不变，如图4所示。

每个文件版本仓库都至少包含一个主分支，还可以包含一个或多个子分支，每个分支都可以有多个版本，每个版本仅保存对其所在分支的上一个版本所做的修改，同时有一条文本信息对修改的内容进行描述，各分支之间通过树状关系保持连接。

HEAD指针用于在用户的要求下指向某个分支，HEAD指针所指向的分支就是当前分支的工作空间，各分支指针指向各自的最新提交。当用户创建了一个新分支时，HEAD指针自动指向所创建的新分支。

所述文件版本仓库能够跟踪并管理当前工作空间内容的修改。用户对文件进行修改，修改过程中，如果用户认为可以形成一个新的版本，那么，用户可以对当前已记录的修改做一个标记，把新版本的修改描述写入所述标记中。修改完毕时，所形成的新版本会自动提交到版本仓库中。

实现团队各成员对所述新分支的共享，有以下两种方式：

1、将所述新分支的文件内容合并到主分支，团队成员可在主分支中看到新分支的文件内容；

2、在所述新分支中，通过设置权限允许团队成员查看该分支的文件内容。

对于第1种方式，将用户创建的新分支与所述主分支进行合并，具体包括：由所述新分支向所述主分支提交合并申请；待所述主分支批准所述合并申请后，将用户创建的新分支与所述主分支进行合并。

将新分支合并到主分支上，需要从新分支发送合并申请给主分支(需要预告对分支设置不同的成员权限，有管理权限的成员可批准合并、执行合并)，有管理权限的成员在收到合并申请后，并不会马上批准所述合并申请，而是需要判断所述主分支是否存在超前提交；

当所述主分支不存在超前提交时，可以批准所述合并申请，然后执行合并，所述超前提交指所述新分支创建后，所述主分支出现的提交；合并有两种方式：第一种是快速合并，如图5所示，将所述主分支的工作空间指所述向新分支的当前提交，并删除所述新分支，删除分支后，会丢掉分支信息；第二种是禁用快速合并，如图6所示，在所述主分支创建一个新的提交，所述新的提交的文件内容与所述新分支上最新提交的文件内容相同，删除所述新分支，完成合并，删除新分支的工作空间后，从分支历史上还可以看出分支信息；

当所述主分支存在超前提交时，如图7所示，如果直接执行合并可能会发生冲突，对所述主分支的工作空间与所述新分支的工作空间相冲突的内容进行标记，并提示用户对所述主分支或所述新分支的工作空间进行修改，此时需要用户手动解决冲突，解决冲突的方式为对主分支的工作空间进行修改，并把提交描述写进去，然后提交一个新的版本，如图8所示，然后删除新分支，如图9所示，完成合并。

在上述步骤S1至步骤S3的基础上，所述方法还可以包括：

版本回退：根据用户的要求，移动所述HEAD指针，使其指向回退的目标分支，同时，更新所述在线文件的工作空间，完成在线文件版本的回退；

当文件内容改乱时，可以在修改快照记录中恢复版本，即，移动HEAD指针使其指向要恢复的分支，文件的工作空间同步更新。版本回退后，在某提交下提交新的修改提交时，自动创建一个新分支，HEAD指针切换到新分支上，在新分支提交新的修改。回退到某个版本后，如果想恢复到新版本，可在操作历史中，确定要回到哪个版本。然后在修改快照记录中找到版本进行恢复。还可以按照用户的要求移动分支指针，使其指向个分支，恢复到该分支所指向的提交，然后在该提交为基础创建一个新的分支，再使HEAD指针指向该新的分支，同时，更新所述在线文件的工作空间，完成版本回退，如图11所示。

下面举例说明分支的创建、合并、以及删除的原理。

综上所述，本申请实施例的具有以下特点：

1、每一个设计文件都是一个在线版本管理仓库，每个仓库都有一个主分支及多个子分支，每个分支可以有多个版本，每个版本仅保存分支上对上一个版本进行的修改，同时有一条文本信息对修改的内容进行描述，分支之间通过树状关系保持连接；

2、团队成员可以对设计文件创建新的分支，在分支上提交新的版本；

3、团队成员在分支上的修改会自动保存并生成新版本，团队成员也可以手动提交来生成新版本；

4、不同分支之间的修改不会互相影响；

5、团队成员可以在同一个分支上进行协同修改；

6、团队成员可以在分支之间切换，可以回退及撤销某个分支上的修改提交；

7、团队成员可以提交将某个子分支(即某一个新分支)合并到主分支的“分支合并请求”

8、团队成员可以对“分支合并请求”进行评审；

9、具有审核权限的团队成员可以接受“分支合并请求，并将子分支合并到主分支”；

10、在分支之间产生冲突时，可以通过在线解决分支之间的冲突并完成分支合并。

11、可以按照合并分支的方法将两个独立在线文件版本仓库中的主分支进行合并，实现修改内容的推送。”

如图12所示，本申请实施例还提供了一种设计文件在线版本管理装置，包括：

初始模块1，其配置成当用户创建在线文件时，为所述在线文件创建文件版本仓库、HEAD指针和版本记录，所述HEAD指针用于指向某个分支，所述分支由同一工作空间的所有版本按照修改时间串连而成，所述文件工作空间指实际的文件内容，所述分支包括主分支和新分支，当只存在一个分支时，该分支称为主分支，所述新分支以所述主分支上的某个版本为起点；

新版本创建模块2，当文件被用户修改时，将修改完的文件版本作为最新版本提交到所述的版本仓库中，并更新所述版本记录；和

合并模块3，其配置成将所述新分支与所述主分支进行合并。

所述装置还包括：

申请模块，其配置成由所述新分支向所述主分支提交合并申请；

判断模块，其配置成判断所述主分支是否存在超前提交；

批准模块，其配置成当所述主分支不存在超前提交时，所述主分支批准所述合并申请，所述超前提交指所述新分支创建后，所述主分支出现的提交；

冲突解决模块，其配置成当所述主分支存在超前提交时，对所述主分支的工作空间与所述新分支的工作空间相冲突的内容进行标记，并提示用户对所述主分支和/或所述新分支的工作空间进行修改。

所述合并模块包括：

工作空间转移子模块，其配置成将所述主分支的工作空间指所述向新分支的当前提交，

第一删除子模块，其配置成删除所述新分支，完成合并。

所述合并模块包括：

新提交创建子模块，其配置成在所述主分支创建一个新的提交；

第二删除子模块，其配置成删除所述新分支，完成合并，所述新的提交的文件内容与所述新分支上最新提交的文件内容相同。

所述装置还包括：

回退模块，其配置成移动所述HEAD指针，使其指向要恢复到的分支，同时，更新所述在线文件的工作空间，完成在线文件版本的回退。

本申请实施例的设计文件在线版本管理装置能够执行本申请实施例的设计文件在线版本管理方法的步骤，其原理及效果在此不再赘述。

本申请实施例还提供了一种计算设备，参照图13，该计算设备包括存储器1120、处理器1110和存储在所述存储器1120内并能由所述处理器1110运行的计算机程序，该计算机程序存储于存储器1120中的用于程序代码的空间1130，该计算机程序在由处理器1110执行时实现用于执行任一项根据本发明的方法步骤1131。

本申请实施例还提供了一种计算机可读存储介质。参照图14，该计算机可读存储介质包括用于程序代码的存储单元，该存储单元设置有用于执行根据本发明的方法步骤的程序1131′，该程序被处理器执行。

本申请实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机上运行时，使得计算机执行根据本发明的方法步骤。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、获取其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令处理器完成，所述的程序可以存储于计算机可读存储介质中，所述存储介质是非短暂性(英文：non-transitory)介质，例如随机存取存储器，只读存储器，快闪存储器，硬盘，固态硬盘，磁带(英文：magnetic tape)，软盘(英文：floppy disk)，光盘(英文：optical disc)及其任意组合。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。