CN111857806A - 权限配置文件更新方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开涉及一种权限配置文件更新方法、装置、电子设备及存储介质。该方法包括：从预设的存储位置中，获取版本信息；其中，版本信息中包括至少一个版本号和至少一个版本号对应的更新文件；从至少一个版本号中，确定出目标版本号；获取目标版本号对应的目标更新文件，集成与目标更新文件对应的权限配置文件；集成与目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行从预设的存储位置中，获取版本信息的步骤，更新权限配置文件。从而能够通过经过第一预设时长后再次更新权限配置文件的方式，避免在一定的时间内出现多次构建权限配置文件的情况，起到对权限配置文件进行有序更新的作用，实现对软件版本的更新进行有序的控制。

Description

权限配置文件更新方法、装置、电子设备及存储介质

技术领域

本公开涉及数据处理技术领域，尤其涉及一种权限配置文件更新方法、装置、电子设备及存储介质。

背景技术

随着互联网技术的不断发展，各种各样的软件开发需求大量涌现。在根据不同的需求进行软件开发的过程中，一个关键的问题是能够有效的实现软件版本的控制。其中，SVN(subversion)是一个开放源代码的版本控制系统，SVN支持完善的按目录设置读写权限的功能，该功能对于较大规模共同研发的团队而言是保证代码安全的重要能力。传统软件版本控制方法中，通常是通过在SVN代码仓库里的不同目录下增加owner文件来描述对该目录的权限控制，在每次更新owner文件过程中，将待更新的owner文件提交到SVN服务器之后，SVN服务器会根据待更新的owner文件重建SVN服务器的权限配置文件，以实现软件版本权限的控制。

然而，通过根据待更新的owner文件重建SVN服务器的权限配置文件的整个过程，需要一定的时间来完成，若在一定的时间内有多次owner文件的变更时，可能会执行多次重建SVN权限配置文件的步骤，导致新的权限配置文件被旧的权限配置文件所覆盖，出现配置管理混乱的状况，无法对软件版本的更新进行有序的控制。

发明内容

本公开提供一种权限配置文件更新方法、装置、电子设备及存储介质，以至少解决相关技术中无法对软件版本的更新进行有序控制的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种权限配置文件更新方法，包括：

从预设的存储位置中，获取版本信息；其中，所述版本信息中包括至少一个版本号和所述至少一个版本号对应的更新文件；

从所述至少一个版本号中，确定出目标版本号；

获取所述目标版本号对应的目标更新文件，集成与所述目标更新文件对应的权限配置文件；

集成与所述目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行所述从预设的存储位置中，获取版本信息的步骤，更新所述权限配置文件。

在一示例性实施例中，所述从预设的存储位置中，获取版本信息之前，包括：

接收用户终端提交的更新文件；

按照所述更新文件的提交时间和提交内容，生成所述版本号；

存储所述更新文件和所述版本号形成的所述版本信息，至所述预设存储位置。

在一示例性实施例中，所述预设存储位置为Redis；所述存储所述更新文件和所述版本号形成的所述版本信息，至所述预设存储位置，包括：

存储所述版本信息至所述Redis。

在一示例性实施例中，所述存储所述版本信息至所述Redis，包括：

比较所述更新文件的提交时间；

存储最新提交时间对应的版本号形成的版本信息至所述Redis。

在一示例性实施例中，所述从预设的存储位置中，获取版本信息，包括：

检测所述预设存储位置中是否存储有所述版本信息；

若所述预设存储位置中存储有所述版本信息，则从所述预设存储位置中获取所述版本信息；

若所述预设存储位置中未存储有所述版本信息，则经过第二预设时长后，返回执行所述检测预设存储位置中是否存储有所述版本信息的步骤。

在一示例性实施例中，所述从所述至少一个版本号中，确定出目标版本号，包括：

筛选所述至少一个版本号，将所述至少一个版本号中的最新版本号，确定为所述目标版本号。

在一示例性实施例中，所述获取所述目标版本号对应的目标更新文件，集成与所述目标更新文件对应的权限配置文件，包括：

按照所述目标版本号查找对应的更新文件，得到所述目标更新文件；

通过SVN版本控制系统集成所述目标更新文件，得到与所述目标更新文件对应的权限配置文件。

根据本公开实施例的第二方面，提供一种权限配置文件更新装置，包括：

版本信息获取单元，被配置为执行从预设的存储位置中，获取版本信息；其中，所述版本信息中包括至少一个版本号和所述至少一个版本号对应的更新文件；

目标版本号确定单元，被配置为执行从所述至少一个版本号中，确定出目标版本号；

权限配置文件集成单元，被配置为执行获取所述目标版本号对应的目标更新文件，集成与所述目标更新文件对应的权限配置文件；

权限配置文件更新单元，被配置为执行集成与所述目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行所述从预设的存储位置中，获取版本信息的步骤，更新所述权限配置文件。

在一示例性实施例中，所述版本信息获取单元还被配置为执行：

接收用户终端提交的更新文件；

按照所述更新文件的提交时间和提交内容，生成所述版本号；

存储所述更新文件和所述版本号形成的所述版本信息，至所述预设存储位置。

在一示例性实施例中，所述预设存储位置为Redis；

所述版本信息获取单元还被配置为执行：

存储所述版本信息至所述Redis。

在一示例性实施例中，所述版本信息获取单元还被配置为执行：

比较所述更新文件的提交时间；

存储最新提交时间对应的版本号形成的版本信息至所述Redis。

在一示例性实施例中，所述版本信息获取单元还被配置为执行：

检测所述预设存储位置中是否存储有所述版本信息；

若所述预设存储位置中存储有所述版本信息，则从所述预设存储位置中获取所述版本信息；

若所述预设存储位置中未存储有所述版本信息，则经过第二预设时长后，返回执行所述检测预设存储位置中是否存储有所述版本信息的步骤。

在一示例性实施例中，所述目标版本号确定单元还被配置为执行：

筛选所述至少一个版本号，将所述至少一个版本号中的最新版本号，确定为所述目标版本号。

在一示例性实施例中，所述权限配置文件集成单元还被配置为执行：

按照所述目标版本号查找对应的更新文件，得到所述目标更新文件；

通过SVN版本控制系统集成所述目标更新文件，得到与所述目标更新文件对应的权限配置文件。根据本公开实施例的第三方面，提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现上述第一方面任一项实施例中所述的权限配置文件更新方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行上述第一方面任一项实施例中所述的权限配置文件更新方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，所述程序产品包括计算机程序，所述计算机程序存储在可读存储介质中，设备的至少一个处理器从所述可读存储介质读取并执行所述计算机程序，使得设备执行上述第一方面任一项实施例中所述的权限配置文件更新方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

从预设的存储位置中，获取版本信息；其中，版本信息中包括至少一个版本号和至少一个版本号对应的更新文件；从至少一个版本号中，确定出目标版本号；获取目标版本号对应的目标更新文件，集成与目标更新文件对应的权限配置文件；集成与目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行从预设的存储位置中，获取版本信息的步骤，更新权限配置文件。其中，从版本信息中的至少一个版本号中确定出目标版本号，并应用目标版本号对应的目标更新文件构建权限配置文件，能够保证在一次权限配置文件的构建过程中，只针对目标版本号对应的目标更新文件进行权限配置文件的构建，同时，经过第一预设时长后再次更新权限配置文件，能够避免在一定的时间内出现多次构建权限配置文件的情况，起到对权限配置文件进行有序更新的作用，实现对软件版本的更新进行有序的控制。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种权限配置文件更新方法的应用环境图。

图2是根据一示例性实施例示出的一种权限配置文件更新方法的流程图。

图3是根据一示例性实施例示出的步骤S100之前的一种可实施方式的流程图。

图4是根据一示例性实施例示出的步骤S100的一种可实施方式的流程图。

图5是根据一示例性实施例示出的步骤S300的一种可实施方式的流程图。

图6是根据一示例性实施例示出的一种权限配置文件更新装置的框图。

图7是根据一示例性实施例示出的一种用于权限配置文件更新的设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种权限配置文件更新方法的应用环境图，本申请提供的权限配置文件更新方法，可以应用于如图1所示的应用环境中。其中，电子设备110通过网络与服务器120进行交互。电子设备110从预设的存储位置中，获取版本信息；其中，版本信息中包括至少一个版本号和至少一个版本号对应的更新文件；从至少一个版本号中，确定出目标版本号；获取目标版本号对应的目标更新文件，集成与目标更新文件对应的权限配置文件；集成与目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行从预设的存储位置中，获取版本信息的步骤，更新权限配置文件。其中，电子设备110可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器120可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

图2是根据一示例性实施例示出的一种权限配置文件更新方法的流程图，如图2所示，以权限配置文件更新方法用于图1中的电子设备110为例进行说明，具体包括以下步骤：

在步骤S100中，从预设的存储位置中，获取版本信息；其中，版本信息中包括至少一个版本号和至少一个版本号对应的更新文件。

在步骤S200中，从至少一个版本号中，确定出目标版本号。

在步骤S300中，获取目标版本号对应的目标更新文件，集成与目标更新文件对应的权限配置文件。

在步骤S400中，集成与目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行从预设的存储位置中，获取版本信息的步骤，更新权限配置文件。

其中，版本信息是指在软件开发过程中，需要进行软件版本更新的信息，包括至少一个待更新的版本号和相应版本号对应的更新信息或更新文件。目标版本号是指需要更新的版本号，在进行权限配置文件的构建时，可能会收到用户提交的多个待更新版本的版本号，其中，满足条件的版本号为当前需要更新到的版本，可选地，将最大的版本号作为当前需要更新到的版本，至少一个版本号中的其余版本号对应的内容可看作是中间版本，并不是最终版本。目标更新文件为目标版本号对应的需要更新的文件。示例地，当进行软件版本控制系统为SVN版本控制系统时，目标更新文件为开发人员更新的owner文件。第一预设时长是指预先设定的间隔时长，可以为0.5分钟、1分钟、2分钟不等，能够使得两次权限配置文件的更新分别进行，保证前序更新已完成，避免并发冲突。

具体地，从预设存储位置(预设存储位置可以为一个特定的Redis)中获取版本信息。从版本信息中的至少一个版本号中，剔除中间版本对应的版本号，确定出当前需要更新到的最终版本号，并将需要更新到的最终版本号确定为目标版本号。例如，在软件开发过程中，为了实现某一特定需求，开发人员开发出了V1版本，在得到V1版本后，可能由于需求的改变或者程序的优化，开发人员对V1版本进行了修改，得到了V2、……、V(n-1)等软件版本，并最终得到Vn版本。将V1、V2、……、Vn等至少一个版本号对应的待更新信息先后提交到SVN服务器，其中，V1、V2、……、V(n-1)均为软件开发过程中的中间版本，无需进行V1、V2、……、V(n-1)文件的更新，直接根据本次软件开发过程中的最终确定版本Vn进行权限配置文件的构建便可获得最终的软件开发版本，则将Vn确定为目标版本号。在得到目标版本号后，查找与目标版本号对应的目标更新文件，应用目标更新文件，更新权限配置文件。

示例地，在集成与目标更新文件对应的权限配置文件的过程中，开发人员可能又对开发项目中的软件进行了部分更新，并将更新文件存储至预设的存储位置进行排队。以一次更新权限配置文件完成时为节点，开始计时，在经过第二预设时长后，重新获取排队的版本信息，并返回执行从版本信息中获取目标版本号，获取目标版本号对应的目标更新文件，并根据目标更新文件，更新权限配置文件，再一次完成软件开发的版本更新。使得相邻两次权限配置文件的更新过程之间有一个时间间隔，避免同时更新产生的并发冲突。

上述权限配置文件更新方法，从预设的存储位置中，获取版本信息；其中，版本信息中包括至少一个版本号和至少一个版本号对应的更新文件；从至少一个版本号中，确定出目标版本号；获取目标版本号对应的目标更新文件，集成与目标更新文件对应的权限配置文件；集成与目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行从预设的存储位置中，获取版本信息的步骤，更新权限配置文件。其中，从版本信息中的至少一个版本号中确定出目标版本号，并应用目标版本号对应的目标更新文件构建权限配置文件，能够保证在一次权限配置文件的构建过程中，只针对目标版本号对应的目标更新文件进行权限配置文件的构建，同时，经过第一预设时长后再次更新权限配置文件，能够避免在一定的时间内出现多次构建权限配置文件的情况，起到对权限配置文件进行有序更新的作用，实现对软件版本的更新进行有序的控制。

图3是根据一具体示例性实施例示出的步骤S100之前的一种可实施方式的流程图，具体包括以下步骤：

在步骤S101中，接收用户终端提交的更新文件。

在步骤S102中，按照更新文件的提交时间和提交内容，生成版本号。

在步骤S103中，存储更新文件和版本号形成的版本信息，至预设存储位置。

其中，用户终端是指软件开发人员对应的用户终端、电子设备等。

具体地，软件开发人员在对开发项目中的程序文件进行修改后，通过用户终端将更新文件提交至服务器。由服务器按照更新文件的提交时间和提交内容，生成版本号。并更新文件和版本号形成的版本信息，存储至预设存储位置。

可选地，预设存储位置为Redis；存储版本信息至Redis。具体地，在将版本信息存储至预设存储位置Redis中时，是将当前的版本号写入Redis中，以保证任意时刻，只会用最新版本信息生成权限配置文件，避免产生并发冲突的情况。

可选地，在将版本信息存储至预设存储位置Redis中时，检测是否有owner文件的更新，若有，则更新到Redis里面；若无owner文件的更新，则无需进行权限配置文件的重建，无需将版本信息存储至Redis中。

可选地，比较更新文件的提交时间；存储最新提交时间对应的版本号形成的版本信息至Redis。

上述示例性实施例中，接收用户终端提交的更新文件；按照更新文件的提交时间和提交内容，生成版本号；存储更新文件和版本号形成的版本信息，至预设存储位置。从而使得获取版本信息时，能够获取当前时刻的版本信息，直至进行权限配置文件的重建，起到对权限配置文件进行有序更新的作用，实现对软件版本的更新进行有序的控制。

图4是根据一具体示例性实施例示出的步骤S100的一种可实施方式的流程图，具体包括以下步骤：

在步骤S110中，检测预设存储位置中是否存储有版本信息。

在步骤S120中，若预设存储位置中存储有版本信息，则从预设存储位置中获取该版本信息。

在步骤S130中，若预设存储位置中未存储有版本信息，则经过第一预设时长后，返回执行检测预设存储位置中是否存储有版本信息的步骤。

其中，预设存储位置是指初始设定的，便于进行存储和读取数据的存储位置。可选地，预设存储位置为在服务器上启动的一个Redis。Redis(远程字典服务，RemoteDictionary Server)，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。第一预设时长为检测预设存储位置中是否存储有版本信息的间隔时间，这一间隔时间的设置能够为每一次的检测提供一个等待时间，以保证上一轮检测充分结束。可选地，第一预设时长可以为10秒、15秒、20秒不等，第一预设时长的设置可以根据具体的用户需求而定，此处不进行具体限制。

具体地，检测预设存储位置中是否存储有版本信息，若预设存储位置中存储有版本信息，则说明当前有开发人员提交的更新信息，需要进行版本更新，需要对待更新的文件进行重建，以更新最新的权限配置文件，此时，从预设存储位置中获取该版本信息，以备后续重建权限配置文件所用。

若预设存储位置中没有版本信息，则说明当前没有开发人员提交更新信息，并不需要进行软件的版本更新，此时，则经过第一预设时长后，返回执行检测预设存储位置中是否存储有版本信息的步骤，当有开发人员提交版本信息到预设存储位置中后，根据更新文件进行权限配置文件的重建，当预设存储位置中没有版本信息时，继续扫描，为获取版本信息并进行权限配置文件重建做准备。

上述示例性实施例中，当检测到存储位置中存储有版本信息时，获取版本信息，为更新权限配置文件提供数据基础，当检测到预设存储位置中未存储有版本信息，则经过第一预设时长后，返回执行检测预设存储位置中是否存储有版本信息的步骤，保持对预设存储位置中是否存储有版本信息进行检测的实时性，以保证在预设存储位置中存储有版本信息时，能及时进行后续的操作，直至更新权限配置文件，起到对权限配置文件进行有序更新的作用，实现对软件版本的更新进行有序的控制。其中，经过第一预设时长后，返回执行检测预设存储位置中是否存储有版本信息的步骤，第一预设时长的设置能够为每一次的检测提供一个等待时间，以保证上一轮检测充分结束，实现软件版本更新的有序进行。

在一示例性实施例中，为步骤S200的一种可实施方式，包括：

筛选至少一个版本号，将至少一个版本号中的最新版本号，确定为目标版本号。

其中，由于在软件开发过程中，为了实现某一需求，开发人员开发出了V1版本，在得到V1版本后，可能由于需求的改变或者程序的优化，开发人员对V1版本进行了修改，得到了V2、……、V(n-1)等版本，并最终得到Vn版本。将V1、V2、……、Vn等至少一个版本号对应的待更新信息先后提交到SVN，其中，V1、V2、……、V(n-1)均为软件开发过程中的中间版本，无需进行V1、V2、……、V(n-1)文件的更新，直接根据本次软件开发过程中的最终确定版本Vn进行权限配置文件的构建便可获得最终的软件开发版本，则将Vn确定为目标版本号。

具体地，在步骤S100中获取到版本信息后，比较版本信息中的至少一个版本号V1、V2、……、Vn，将至少一个版本号V1、V2、……、Vn的最终版本号(最新版本号/最终版本号)确定为需要进行SVN权限配置文件重建的目标版本号。

上述示例性实施例中，筛选至少一个版本号，将至少一个版本号中的最新版本号，确定为目标版本号。在确定出目标版本号后，应用目标版本号对应的目标更新文件构建权限配置文件，能够保证在一次权限配置文件的构建过程中，只针对目标版本号对应的目标更新文件进行权限配置文件的构建，避免在一定的时间内出现多次构建权限配置文件的情况，起到有序进行权限配置文件的配置管理的作用，实现对软件版本进行有序的控制。

图5是根据一具体示例性实施例示出的步骤S300的一种可实施方式的流程图，具体包括以下步骤：

在步骤S310中，按照目标版本号查找对应的更新文件，得到目标更新文件。

在步骤S320中，通过SVN版本控制系统集成目标更新文件，得到与目标更新文件对应的权限配置文件。

具体地，根据目标版本号扫描所有的更新文件(owner文件)，将目标版本号对应的更新文件确定为目标更新文，通过SVN版本控制系统，应用目标更新文件更新权限配置文件。

其中，SVN版本控制系统是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，即用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。SVN版本控制系统支持完善的按目录设置读写权限的功能，该功能对于较大规模共同研发的团队而言是保证代码安全的重要能力。

具体地，SVN版本控制系统更新权限配置文件的过程为：通过在SVN代码仓库里的不同目录下增加owner文件来描述对该目录的权限控制，每次更新owner文件并提交到SVN服务器后，SVN服务器会通过一个postcommit机制扫描所有的owner文件来重建SVN服务器的权限配置文件auth.conf。

SVN版本控制系统是是通过在任一台服务器中添加一个SVN版本库，而相应的版本库中存放大量的程序和文档，这些项目资源主要通过配置管理员依据不同的配置管理计划对不同项目的组员分配与之相符合的访问权限，进而实现对资源的统一管理；只有SVN标本过版本库中的资源，项目组成员可以对版本资源库中的资源进行访问。

一次简单的访问过程包括：相关项目组员首先在客户操作端建立一个从版本库检索出来的项目文件，而后就可以对拷贝的档案进行修改，最后通过SVN提交命令将其修改后的项目文件提交到终端服务器，终端服务器最终会对修改后的项目文件做最后的综合更新记录。修改过的文件在修改未被提交到服务器前，SVN服务器只会对已经提交到网络端服务器的项目文档进行更新审核，并与其他人的合并，在此之前修改过的文档是保密的，提交之后SVN络端服务器会将修改后与修改之前的数据进行比较，并在后台对修改内容就行标注显示，进而实现对历史操作记录的更新记载。最终实现项目组组员既能检索出旧版本，又能通过SVN实现新旧版本的对比，另一方面SVN通过进行组员间的协同开发实现对项目软件的版本控制。协同开发一般是指版本控制系统间接受并处理不同用户提交的各种不同性质版本的资源代码，同时允许各个用户之间在遵循相应规则范围内实现合作开发。如何处理好有矛盾的版本控制系统才是能够协同开发的关键，像是多个程序编码员同时对同一份资源代码进行修改、提交到SVN版本库，就有可能发生提交后的版本意见想法相冲等问题。

上述示例性实施例中，按照目标版本号查找对应的更新文件，得到目标更新文件；通过SVN版本控制系统集成目标更新文件，得到与目标更新文件对应的权限配置文件。从而能够按照目标版本号查找对应的更新文件，得到目标更新文件，仅针对需要更新的owner文件进行SVN权限配置文件，避免不必要的更新，避免文件更新中可能存在的并发冲突。

在一个具体的示例性实施例中，实现对软件版本进行有序的控制，生成SVN权限配置文件包括以下方法：

在服务器上启动一个Redis，然后启动一个常驻执行的脚本程序，读取Redis中的版本信息，并从版本信息中获取当前所有的版本号信息，取出最大的版本号(目标版本号)，执行用owner文件(目标更新文件)生成权限配置文件auth.conf(SVN权限配置文件)的过程。若在Redis中未读取到版本信息，或者已经正常生成权限配置文件auth.conf(SVN权限配置文件)，则暂停10秒钟，继续执行读取Redis中的版本信息的步骤。可选地，在服务器上启动一个Redis的过程是有一个postcommit执行的脚本逻辑的，将这一逻辑确定为每次postcommit执行的时候只是把当前提交到SVN服务器的版本号写入Redis中。可选地，当有OWER文件的修改时，将SVN服务器的版本号写入Redis中。以保证任意单一时刻，只会用最新版本的数据生成一个auth.conf，避免产生并发冲突的情况。

上述具体示例性实施例中，从版本信息中获取目标版本号，并应用目标版本号对应的目标更新文件构建SVN权限配置文件，能够保证在一次SVN权限配置文件的构建过程中，只针对目标版本号对应的目标更新文件进行，避免在一定的时间内多次构建SVN权限配置文件的过程，起到有序进行SVN权限配置文件的配置管理的作用，实现对软件版本进行有序的控制。

应该理解的是，虽然图2-5的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-5中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

图6是根据一示例性实施例示出的一种权限配置文件更新装置框图。参照图6，该权限配置文件更新装置包括版本信息获取单元601、目标版本号确定单元602、权限配置文件集成单元603和权限配置文件更新单元604：

版本信息获取单元601，被配置为执行从预设的存储位置中，获取版本信息；其中，版本信息中包括至少一个版本号和至少一个版本号对应的更新文件；

目标版本号确定单元602，被配置为执行从至少一个版本号中，确定出目标版本号；

权限配置文件集成单元603，被配置为执行获取目标版本号对应的目标更新文件，集成与目标更新文件对应的权限配置文件；

权限配置文件更新单元604，被配置为执行集成与目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行从预设的存储位置中，获取版本信息的步骤，更新权限配置文件。

在一示例性实施例中，版本信息获取单元601还被配置为执行：接收用户终端提交的更新文件；按照更新文件的提交时间和提交内容，生成版本号；存储更新文件和版本号形成的版本信息，至预设存储位置。

在一示例性实施例中，预设存储位置为Redis；版本信息获取单元601还被配置为执行：存储版本信息至Redis。

在一示例性实施例中，版本信息获取单元601还被配置为执行：比较更新文件的提交时间；存储最新提交时间对应的版本号形成的版本信息至Redis。

在一示例性实施例中，版本信息获取单元601还被配置为执行：检测预设存储位置中是否存储有版本信息；若预设存储位置中存储有版本信息，则从预设存储位置中获取版本信息；若预设存储位置中未存储有版本信息，则经过第二预设时长后，返回执行检测预设存储位置中是否存储有版本信息的步骤。

在一示例性实施例中，目标版本号确定单元602还被配置为执行：筛选至少一个版本号，将至少一个版本号中的最新版本号，确定为目标版本号。

在一示例性实施例中，权限配置文件集成单元603还被配置为执行：按照目标版本号查找对应的更新文件，得到目标更新文件；通过SVN版本控制系统集成目标更新文件，得到与目标更新文件对应的权限配置文件。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是根据一示例性实施例示出的一种用于权限配置文件更新的设备700的框图。例如，设备700可以是移动电话、计算机、数字广播终端、消息收发设备、游戏控制台、平板设备、医疗设备、健身设备、个人数字助理等。

参照图7，设备700可以包括以下一个或多个组件：处理组件702、存储器704、电力组件706、多媒体组件708、音频组件710、输入/输出(I/O)的接口712、传感器组件714以及通信组件716。

处理组件702通常控制设备700的整体操作，诸如与显示、电话呼叫、数据通信、相机操作和记录操作相关联的操作。处理组件702可以包括一个或多个处理器720来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件702可以包括一个或多个模块，便于处理组件702和其他组件之间的交互。例如，处理组件702可以包括多媒体模块，以方便多媒体组件708和处理组件702之间的交互。

存储器704被配置为存储各种类型的数据以支持在设备700的操作。这些数据的示例包括用于在设备700上操作的任何应用程序或方法的指令、联系人数据、电话簿数据、消息、图片、视频等。存储器704可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)、电可擦除可编程只读存储器(EEPROM)、可擦除可编程只读存储器(EPROM)、可编程只读存储器(PROM)、只读存储器(ROM)、磁存储器、快闪存储器、磁盘或光盘。

电源组件706为设备700的各种组件提供电力。电源组件706可以包括电源管理系统，一个或多个电源，及其他与为设备700生成、管理和分配电力相关联的组件。

多媒体组件708包括在设备700和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件708包括一个前置摄像头和/或后置摄像头。当设备700处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件710被配置为输出和/或输入音频信号。例如，音频组件710包括一个麦克风(MIC)，当设备700处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器704或经由通信组件716发送。在一些实施例中，音频组件710还包括一个扬声器，用于输出音频信号。

I/O接口712为处理组件702和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件714包括一个或多个传感器，用于为设备700提供各个方面的状态评估。例如，传感器组件714可以检测到设备700的打开/关闭状态，组件的相对定位，例如组件为设备700的显示器和小键盘，传感器组件714还可以检测设备700或设备700一个组件的位置改变，用户与设备700接触的存在或不存在，设备700方位或加速/减速和设备700的温度变化。传感器组件714可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件714还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件714还可以包括加速度传感器、陀螺仪传感器、磁传感器、压力传感器或温度传感器。

通信组件716被配置为便于设备700和其他设备之间有线或无线方式的通信。设备700可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件716经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件716还包括近场通信(NFC)模块，以促进短程通信。

在示例性实施例中，设备700可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在一示例性实施例中，还提供了一种电子设备，包括：处理器720；用于存储处理器可执行指令的存储器；其中，处理器720被配置为执行指令，以实现上述任一项实施例中的权限配置文件更新方法。

在一示例性实施例中，还提供了一种存储介质，当存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行任一项实施例中的权限配置文件更新方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器704，上述指令可由设备700的处理器720执行以完成上述方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种权限配置文件更新方法，其特征在于，包括：

从预设的存储位置中，获取版本信息；其中，所述版本信息中包括至少一个版本号和所述至少一个版本号对应的更新文件；

从所述至少一个版本号中，确定出目标版本号；

获取所述目标版本号对应的目标更新文件，集成与所述目标更新文件对应的权限配置文件；

集成与所述目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行所述从预设的存储位置中，获取版本信息的步骤，更新所述权限配置文件。

2.根据权利要求1所述的权限配置文件更新方法，其特征在于，所述从预设的存储位置中，获取版本信息之前，包括：

接收用户终端提交的更新文件；

按照所述更新文件的提交时间和提交内容，生成所述版本号；

存储所述更新文件和所述版本号形成的所述版本信息，至所述预设存储位置。

3.根据权利要求2所述的权限配置文件更新方法，其特征在于，所述预设存储位置为Redis；

所述存储所述更新文件和所述版本号形成的所述版本信息，至所述预设存储位置，包括：

存储所述版本信息至所述Redis。

4.根据权利要求3所述的权限配置文件更新方法，其特征在于，所述存储所述版本信息至所述Redis，包括：

比较所述更新文件的提交时间；

存储最新提交时间对应的版本号形成的版本信息至所述Redis。

5.根据权利要求1所述的权限配置文件更新方法，其特征在于，所述从预设的存储位置中，获取版本信息，包括：

检测所述预设存储位置中是否存储有所述版本信息；

若所述预设存储位置中存储有所述版本信息，则从所述预设存储位置中获取所述版本信息；

若所述预设存储位置中未存储有所述版本信息，则经过第二预设时长后，返回执行所述检测预设存储位置中是否存储有所述版本信息的步骤。

6.根据权利要求1所述的权限配置文件更新方法，其特征在于，所述从所述至少一个版本号中，确定出目标版本号，包括：

筛选所述至少一个版本号，将所述至少一个版本号中的最新版本号，确定为所述目标版本号。

7.根据权利要求1所述的权限配置文件更新方法，其特征在于，所述获取所述目标版本号对应的目标更新文件，集成与所述目标更新文件对应的权限配置文件，包括：

按照所述目标版本号查找对应的更新文件，得到所述目标更新文件；

通过SVN版本控制系统集成所述目标更新文件，得到与所述目标更新文件对应的权限配置文件。

8.一种权限配置文件更新装置，其特征在于，包括：

版本信息获取单元，被配置为执行从预设的存储位置中，获取版本信息；其中，所述版本信息中包括至少一个版本号和所述至少一个版本号对应的更新文件；

目标版本号确定单元，被配置为执行从所述至少一个版本号中，确定出目标版本号；

权限配置文件集成单元，被配置为执行获取所述目标版本号对应的目标更新文件，集成与所述目标更新文件对应的权限配置文件；

权限配置文件更新单元，被配置为执行集成与所述目标更新文件对应的权限配置文件后开始计时，经过第一预设时长后，返回执行所述从预设的存储位置中，获取版本信息的步骤，更新所述权限配置文件。

9.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至7中任一项所述的权限配置文件更新方法。

10.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至7中任一项所述的权限配置文件更新方法。

Images