本发明涉及版本控制技术领域,尤其涉及一种项目共享文件多人协同开发方法、装置及系统。
背景技术:
版本控制实现了多人协作编辑和文件共享,和其他共享资源类似,在版本控制中,如何保证团队的每个成员编辑的内容不会被他人覆盖或者修改,成为了当前最为突出的问题。为了解决这一问题,不同的版本控制系统使用了不同的策略,目前使用的策略主要包括锁定-修改-解锁策略和拷贝-修改-合并策略两种。
当前项目一般规模较大,采用拷贝-修改-合并策略进行项目管理的企业越来越多。拷贝-修改-合并策略的核心思想是:多人同步开发,先更新再提交,一旦冲突,人为解决。拷贝-修改-合并策略并行开发,时间短,却运行稳定,在交流充足的情况下,冲突很少,但是,无法完全避免冲突,一旦发生冲突,只能人为解决,对团队成员要求较高,且交流成本较高。
技术实现要素:
本发明提供一种项目共享文件多人协同开发方法、装置及系统,减少了配置文件更新冲突,提高了研发效率。
本发明采用以下技术方案:
第一方面,本发明提供一种项目共享文件多人协同开发方法,包括:
将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件;
记录每个配置文件的操作记录;
对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数;
如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件。
示例性地,所述操作记录包括配置文件的增加、删除、修改及查询,操作人员标识,操作时间和冲突次数。
可选地,每个所述任务单位对应的配置文件由该任务单元对应的子任务单位所对应的配置文件合成。
进一步地,所述为所述子任务单位分别新建对应的配置文件之后,还包括:
接收到提交配置文件指令,判断提交的配置文件是否已经存在,如果提交的配置文件已经存在,则覆盖原有的配置文件;如果提交的配置文件不存在,则生成新的配置文件。
进一步地,所述如果提交的配置文件不存在,则生成新的配置文件之后,还包括:
接收到编译指令,读取当前所有任务单位对应的配置文件,自动生成代码。
可选地,所述配置文件采用protocolbuffer文件。
进一步地,所述接收到编译指令,读取当前所有任务单位对应的配置文件,自动生成代码之后,还包括:
将所述自动生成的代码提交至版本控制服务器备份。
第二方面,本发明提供一种项目共享文件多人协同开发装置,包括:
配置文件建立单元,用于将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件;
操作记录记录单元,用于记录每个配置文件的操作记录;
冲突次数统计单元,用于对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数;
配置文件拆分单元,用于如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件。
进一步地,还包括:
配置文件提交单元,用于接收到提交配置文件指令,判断提交的配置文件是否已经存在,如果提交的配置文件已经存在,则覆盖原有的配置文件;如果提交的配置文件不存在,则生成新的配置文件;
配置文件编译单元,用于接收到编译指令,读取当前所有任务单位新建的配置文件,自动生成代码;
代码提交单元,用于将所述自动生成的代码提交至版本控制服务器备份。
所述操作记录包括配置文件的增加、删除、修改及查询,操作人员标识,操作时间和冲突次数;
每个所述任务单位对应的配置文件由该任务单元对应的子任务单位所对应的配置文件合成。
第三方面,本发明提供一种项目共享文件多人协同开发系统,包括配置文件管理服务器和客户端,所述配置文件管理服务器配置有上述所述的项目共享文件多人协同开发装置,
配置文件管理服务器将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件;
客户端编辑对应的配置文件,在配置文件中添加属性,判断每条属性是否合法,如果属性合法,则将所述属性添加入所述配置文件,将编辑完成的配置文件提交至配置文件管理服务器;
配置文件管理服务器判断提交的配置文件是否已经存在,如果提交的配置文件已经存在,则覆盖原有的配置文件;如果提交的配置文件不存在,则生成新的配置文件;记录每个配置文件的操作记录,对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数;如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件。
本发明提供的技术方案带来如下有益效果:
通过对存在更新冲突的配置文件对应的任务单位进一步划分,将任务更加细化,任务单位与任务单位之间的关联性更小,尽可能的减少甚至避免分支开发中的冲突问题,从而减少甚至避免当前版本控制系统中必须人为解决冲突的情况,将必然共享的文件根据分支开发的情况拆分成多个任务单位,每个任务单位有且仅有一个配置文件,任务单位通过配置文件可有效避免与他人和自己的冲突问题。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对本发明实施例描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据本发明实施例的内容和这些附图获得其他的附图。
图1是本发明实施例提供的项目共享文件多人协同开发方法第一个实施例的方法流程图。
图2是本发明实施例提供的项目共享文件多人协同开发方法第二个实施例的方法流程图。
图3是本发明实施例提供的项目共享文件多人协同开发方法第三个实施例的方法流程图。
图4是本发明实施例提供的项目共享文件多人协同开发方法第四个实施例的方法流程图。
图5是本发明实施例提供的项目共享文件多人协同开发装置第一个实施例的结构方框图。
图6是本发明实施例提供的项目共享文件多人协同开发装置第二个实施例的结构方框图。
图7是本发明实施例提供的项目共享文件多人协同开发装置第三个实施例的结构方框图。
图8是本发明实施例提供的项目共享文件多人协同开发装置第四个实施例的结构方框图。
图9是本发明实施例提供的项目共享文件多人协同开发系统的系统示意图。
具体实施方式
为使本发明解决的技术问题、采用的技术方案和达到的技术效果更加清楚,下面将结合附图对本发明实施例的技术方案作进一步的详细描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1是本发明实施例提供的项目共享文件多人协同开发方法第一个实施例的方法流程图。该项目共享文件多人协同开发方法运行于配置文件管理服务器,其基于一种理想化的分支开发流程,在版本控制过程中需要多人编辑的文件比较少;针对这些必然共享的编辑文件采用本实施例技术方案解决合并冲突的问题。该项目共享文件多人协同开发方法,包括:
s101、将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件。
本实施例中,第一预设规则可以是按照参与单位进行划分,也可以是按照项目的功能模块进行划分,具体划分方式可以根据项目特点进行决定,这里不做具体限制。比如,将项目按照功能模块划分为多个任务单位,每个任务单位由单独一个功能工作单位负责,那么为每个任务单位建立唯一的配置文件,即每个工作单位唯一对应一个配置文件。
配置文件的格式和规则也可自行定制,且同一个项目一般都是特定的编程语言,配置文件包括通用模式和定制模式。具体地,配置文件选用通用模式时,配置文件可以采用go语言的protocolbuffer文件。go语言是谷歌2009年发布的第二款开源编程语言。go语言专门针对多处理器系统应用程序的编程进行了优化,使用go编译的程序可以媲美c或c++代码的速度,而且更加安全、支持并行进程。protocolbuffer是google的一种数据交换的格式,它独立于语言,独立于平台。google提供了三种语言的实现:java、c++和python,每一种实现都包含了相应语言的编译器以及库文件。由于它是一种二进制的格式,比使用xml进行数据交换快许多。
配置文件的定制模式可以选择脚本这样的解释性语言,可以将对其他分支的影响降到最低。如果分支开发的划分比较合理,共享文件的结构都是较为结构化甚至标准化,这个进一步的降低了定制配置文件编译的难度。
每个配置文件的命名可以根据工作单位命名,或者制订一套命名规则,以唯一确定工作单位对应的配置文件。
s102、记录每个配置文件的操作记录。
所述操作记录可以包括配置文件的增加、删除、修改及查询,操作人员标识,操作时间和冲突次数。
具体地,在增加配置文件时,为配置文件分配内存;在删除配置文件时,回收该配置文件的内存。
每个工作单位对应的配置文件可能有多个研发人员进行操作,那么在编辑配置文件时就需要登记操作人员的标识,以确定是谁进行了该次配置文件的编辑,操作人员标识可以是姓名、身份证号或者工号,因为姓名通常存在重名的情况,优先选用操作人员的工号。
s103、对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数。
在每次提交配置文件时,会对该配置文件与其对应的原始配置文件进行比较,如果存在冲突,则冲突次数加1。
s104、如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件。
预设次数可以为3次,也可以为5次,这里不做具体限制。如果某个配置文件出现冲突,则说明该配置文件对应的任务单位划分不够合理,则根据第二预设规则对该任务单位进一步进行划分,根据具体冲突内容将该任务单位划分为多个子任务单位,并为每个子任务单位分别建立对应的配置文件,任务单位对应的配置文件作为子任务单位对应配置文件的上级文件。
具体地,每个所述任务单位对应的配置文件由该任务单元对应的子任务单位所对应的配置文件合成。
那么,对于子任务单位也可以根据冲突次数再次进行任务划分,如此经过划分后的每个任务对应的配置文件在提交时基本消除了冲突的情况,任务单位相对独立。
对于项目初始任务单位划分时则采用历史经验初步划分,在实际进程中进一步对任务单位细分。
综上,本发明实施例提供的项目共享文件多人协同开发方法将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件,记录每个配置文件的操作记录,对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数,如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件,通过对存在更新冲突的配置文件对应的任务单位进一步划分,将任务更加细化,任务单位与任务单位之间的关联性更小,尽可能的减少甚至避免分支开发中的冲突问题,从而减少甚至避免当前版本控制系统中必须人为解决冲突的情况,将必然共享的文件根据分支开发的情况拆分成多个任务单位,每个任务单位有且仅有一个配置文件,任务单位通过配置文件可有效避免与他人和自己的冲突问题。
图2是本发明实施例提供的项目共享文件多人协同开发方法第二个实施例的方法流程图。该项目共享文件多人协同开发方法以图1所示方法为基础,进一步包括:
s205、接收到提交配置文件指令,判断提交的配置文件是否已经存在,如果提交的配置文件已经存在,则覆盖原有的配置文件;如果提交的配置文件不存在,则生成新的配置文件。
所有配置文件使用同一套命名规则,当用户编辑完配置文件后,提交配置文件时,将提交的配置文件的名称与所有配置文件的名称进行匹配,如果匹配到相同名称的配置文件则直接进行覆盖;反之,则生成新的配置文件。
综上,本发明实施例提供的项目共享文件多人协同开发方法采用每次提交的配置文件覆盖其对应的原始配置文件,保证每个任务单位仅有一个配置文件,从宽度和广度上都避免了冲突的可能性,有利于提高研发效率。
图3是本发明实施例提供的项目共享文件多人协同开发方法第三个实施例的方法流程图。该项目共享文件多人协同开发方法以图2所示方法为基础,进一步包括:
s306、接收到编译指令,读取当前所有任务单位对应的配置文件,自动生成代码。
本实施例中,配置文件采用go语言的protocolbuffer文件。google提供了三种语言的实现:java、c++和python,每一种实现都包含了相应语言的编译器以及库文件。采用现有的文件格式,不必再研发对应的编译器,使用其配套的编译器就可以实现配置文件的编译生成代码。
综上,本发明实施例提供的项目共享文件多人协同开发方法对所有配置文件进行编译生成代码,由于所有配置文件不存在冲突,因此,生成的代码是没有冲突的,对配置文件统一编译打包,提高了处理效率。
图4是本发明实施例提供的项目共享文件多人协同开发方法第四个实施例的方法流程图。该项目共享文件多人协同开发方法以图3所示方法为基础,进一步包括:
s407、将所述自动生成的代码提交至版本控制服务器备份。
本实施例中,使用svn(subversion,svn)版本控制系统,将自动生成的代码上传至svn版本控制系统进行该版本的保存,便于后续开发时查找问题,及回退到之前的版本。
综上,本发明实施例提供的项目共享文件多人协同开发方法自动生成的代码是解决了冲突的代码,因此,在提交至版本控制服务器时是不会出现冲突情况的,避免了人为解决冲突费时费力,提高了研发效率。
图5是本发明实施例提供的项目共享文件多人协同开发装置第一个实施例的结构方框图。该项目共享文件多人协同开发装置用于执行图1所示的方法。参考图5所示,该项目共享文件多人协同开发装置包括:
配置文件建立单元100,用于将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件;
操作记录记录单元101,用于记录每个配置文件的操作记录;所述操作记录包括配置文件的增加、删除、修改及查询,操作人员标识,操作时间和冲突次数;
冲突次数统计单元102,用于对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数;
配置文件拆分单元103,用于如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件;每个所述任务单位对应的配置文件由该任务单元对应的子任务单位所对应的配置文件合成。
综上,本发明实施例提供的项目共享文件多人协同开发装置将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件,记录每个配置文件的操作记录,对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数,如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件,通过对存在更新冲突的配置文件对应的任务单位进一步划分,将任务更加细化,任务单位与任务单位之间的关联性更小,尽可能的减少甚至避免分支开发中的冲突问题,从而减少甚至避免当前版本控制系统中必须人为解决冲突的情况,将必然共享的文件根据分支开发的情况拆分成多个任务单位,每个任务单位有且仅有一个配置文件,任务单位通过配置文件可有效避免与他人和自己的冲突问题。
图6是本发明实施例提供的项目共享文件多人协同开发装置第二个实施例的结构方框图。该装置基于图5所示的装置,参考图6所示,该项目共享文件多人协同开发装置进一步还包括:
配置文件提交单元104,用于接收到提交配置文件指令,判断提交的配置文件是否已经存在,如果提交的配置文件已经存在,则覆盖原有的配置文件;如果提交的配置文件不存在,则生成新的配置文件。
综上,本发明实施例提供的项目共享文件多人协同开发装置采用每次提交的配置文件覆盖其对应的原始配置文件,保证每个任务单位仅有一个配置文件,从宽度和广度上都避免了冲突的可能性,有利于提高研发效率。
图7是本发明实施例提供的项目共享文件多人协同开发装置第三个实施例的结构方框图。该装置基于图6所示的装置,参考图7所示,该项目共享文件多人协同开发装置进一步还包括:
配置文件编译单元105,用于接收到编译指令,读取当前所有任务单位新建的配置文件,自动生成代码。
综上,本发明实施例提供的项目共享文件多人协同开发装置对所有配置文件进行编译生成代码,由于所有配置文件不存在冲突,因此,生成的代码是没有冲突的,对配置文件统一编译打包,提高了处理效率。
图8是本发明实施例提供的项目共享文件多人协同开发装置第四个实施例的结构方框图。该装置基于图7所示的装置,参考图8所示,该项目共享文件多人协同开发装置进一步还包括:
代码提交单元106,用于将所述自动生成的代码提交至版本控制服务器备份。
综上,本发明实施例提供的项目共享文件多人协同开发方法自动生成的代码是解决了冲突的代码,因此,在提交至版本控制服务器时是不会出现冲突情况的,避免了人为解决冲突费时费力,提高了研发效率。
图9是本发明实施例提供的项目共享文件多人协同开发系统的系统示意图。参考图9所示,该项目共享文件多人协同开发系统包括配置文件管理服务器1和客户端2,所述配置文件管理服务器1配置有上述所述的项目共享文件多人协同开发装置10,
配置文件管理服务器1将所述项目按照第一预设规则划分为多个任务单位,为每个所述任务单位新建唯一的配置文件;
客户端2编辑对应的配置文件,在配置文件中添加属性,判断每条属性是否合法,如果属性合法,则将所述属性添加入所述配置文件,将编辑完成的配置文件提交至配置文件管理服务器1;
配置文件管理服务器1判断提交的配置文件是否已经存在,如果提交的配置文件已经存在,则覆盖原有的配置文件;如果提交的配置文件不存在,则生成新的配置文件;记录每个配置文件的操作记录,对所述操作记录进行分析处理,统计出每个所述配置文件更新时的冲突次数;如果所述冲突次数大于预设次数阈值时,则对所述冲突次数大于预设次数阈值的配置文件所对应的任务单位按照第二预设规则划分为子任务单位,并为所述子任务单位分别新建对应的配置文件。
综上,本发明实施例提供的项目共享文件多人协同开发系统通过对存在更新冲突的配置文件对应的任务单位进一步划分,将任务更加细化,任务单位与任务单位之间的关联性更小,尽可能的减少甚至避免分支开发中的冲突问题,从而减少甚至避免当前版本控制系统中必须人为解决冲突的情况,将必然共享的文件根据分支开发的情况拆分成多个任务单位,每个任务单位有且仅有一个配置文件,任务单位通过配置文件可有效避免与他人和自己的冲突问题。
以上内容仅为本发明的较佳实施例,对于本领域的普通技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,本说明书内容不应理解为对本发明的限制。