CN112181481A

CN112181481A - Authority updating method and device of version management system

Info

Publication number: CN112181481A
Application number: CN202011051753.7A
Authority: CN
Inventors: 顾平
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-09-29
Filing date: 2020-09-29
Publication date: 2021-01-05

Abstract

The disclosure relates to a method and a device for updating authority of a version management system, wherein the method for updating the authority of the version management system comprises the following steps: when an authority updating command of a version management system is received, generating a first version number of the authority updating command, wherein the authority updating command is used for requesting to update an authority configuration file of the version management system; executing the operation of locking a lock file, wherein the lock file is used for maintaining the version number of the permission updating command; if the locking of the lock file is successful, reading a second version number of the permission updating command stored in the lock file; and if the second version number is smaller than the first version number, writing the first version number into the lock file to replace the second version number, reading the account identification recorded in the authority file stored under each directory of the version management system, and updating the account identification with the control authority of each directory into the account identification read from the authority file under the directory in the authority configuration file.

Description

Authority updating method and device of version management system

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for updating permissions of a version management system.

Background

At present, an svn (version) of an open source code is generally adopted in a version management system, and efficient management of a branch management system is adopted, so that a plurality of developers can conveniently develop the same project together, and shared resources and centralized management are realized.

The SVN provides a relatively perfect authority management capability, and can control read-write authorities of different users under different directories. Under the default function provided by the SVN, the strategy of authority management is that a system administrator modifies a global authority configuration file through the SVN, and modifies the authority of related personnel in the authority configuration file.

By adopting the existing mode, because the authority for modifying the authority configuration file is only owned by the SVN administrator, each time the authority is changed, the personnel needing to be changed contact the SVN administrator to operate, if more developers use the same code warehouse, the operations of adding, deleting and modifying the authority of the personnel can be frequent, the workload of the SVN administrator is increased, the bottleneck is easy to form, and the authority management efficiency of the version management system is reduced.

Disclosure of Invention

The present disclosure provides a method and an apparatus for updating a right of a version management system, so as to at least solve the problem of low efficiency of the right management of the version management system in the related art. The technical scheme of the disclosure is as follows:

according to a first aspect of the embodiments of the present disclosure, there is provided a method for updating a right of a version management system, including:

when an authority updating command of a version management system is received, generating a first version number of the authority updating command, wherein the authority updating command is used for requesting to update an authority configuration file of the version management system by utilizing authority files stored in various directories of the version management system;

executing an operation of locking a lock file, wherein the lock file is used for maintaining the version number of the permission updating command;

if the locking of the lock file is successful, reading a second version number of the permission updating command stored in the lock file;

and if the second version number is smaller than the first version number, writing the first version number into the lock file to replace the second version number, reading account identifications recorded in authority files stored under various directories of the version management system, and updating the account identifications with the control authority of the various directories into the account identifications read from the authority files under the directories in the authority configuration file to update the authority configuration file.

Optionally, after the updating the account identifier having the control authority of each directory to the account identifier read from the authority file under the directory, the method further includes:

and releasing the lock file.

Optionally, updating the account identifier having the control authority of each directory to the account identifier read from the authority file under the directory includes:

generating a new authority configuration file, and recording account identifications with the control authority of each directory in the new authority configuration file as account identifications read from the authority files under the directory;

and replacing the current authority configuration file of the version management system with the new authority configuration file.

Optionally, if the locking of the lock file fails, the method further includes:

and after waiting for a preset time, trying to lock the lock file again, and if the locking is successful, executing the step of reading the second version number stored in the lock file.

Optionally, if the second version number is greater than the first version number, the method further includes:

and releasing the lock file.

Optionally, the permission update command includes: an upload command of a code file of the version management system.

According to a second aspect of the embodiments of the present disclosure, there is provided an authority updating apparatus of a version management system, including:

the version management system comprises a generating unit, a generating unit and a judging unit, wherein the generating unit is configured to generate a first version number of an authority updating command when the authority updating command of a version management system is received, and the authority updating command is used for requesting to update an authority configuration file of the version management system by utilizing the authority files stored under various directories of the version management system;

a control unit configured to perform an operation of locking a lock file, wherein the lock file is used to maintain a version number of the permission update command;

the reading unit is configured to execute the step of reading a second version number of the permission updating command stored in the lock file if the lock file is successfully locked;

and the updating unit is configured to write the first version number into the lock file to replace the second version number if the second version number is smaller than the first version number, read account identifications recorded in authority files stored under various directories of the version management system, and update the account identifications with the control authority of the various directories into the account identifications read from the authority files under the directories in the authority configuration file to update the authority configuration file.

Optionally, the control unit is further configured to perform: and after the account identification with the control authority of each directory is updated to the account identification read from the authority file under the directory, releasing the lock file.

Optionally, the updating unit updates the account identifier having the control authority of each directory to the account identifier read from the authority file under the directory, including:

Optionally, the control unit is further configured to perform: and if the locking of the lock file fails, the target file is tried to be locked again after waiting for a preset time, and if the locking is successful, the reading unit is triggered to read the second version number stored in the lock file.

Optionally, the control unit is further configured to release the lock file if the second version number is greater than the first version number.

According to a third aspect of the embodiments of the present disclosure, there is provided an authority updating apparatus of a version management system, including:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the rights updating method of the version management system as described above.

According to a fourth aspect of the embodiments of the present disclosure, there is provided a storage medium, when instructions in the storage medium are executed by a processor in an authority updating apparatus of a version management system, the authority updating apparatus of the version management system is enabled to execute the authority updating method of the version management system as described above.

According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product comprising at least one non-transitory computer-readable medium storing instructions translatable by at least one processor for implementing the aforementioned method of rights updating of a version management system.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

when an authority updating command of a version management system is received, a first version number of the authority updating command is generated, locking operation on a lock file is executed, if the lock file is successfully locked, a second version number of the authority updating command stored in the lock file is read, if the second version number is smaller than the first version number, the first version number is written into the lock file to replace the second version number, account identifications recorded in authority files stored under various directories of the version management system are read, in the authority configuration file, the account identifications with the control authority of the directories are updated to the account identifications read from the authority files under the directories, and updating of the authority configuration file is achieved. Therefore, the authority configuration file of the version management system can be updated through the updated target authority file. Therefore, the user who already has the authority of the target directory can bear the responsibility of maintaining the authority of the target directory, the pressure of an administrator of the version management system is shared, the authority management efficiency of the version management system is further improved, and the smooth development of large projects is easier to support.

In addition, the problem of confusion of configuration management caused by the fact that a new authority configuration file is covered by an old authority configuration file can be avoided by locking the lock file.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure and are not to be construed as limiting the disclosure.

FIG. 1 is a flow diagram illustrating a method for rights updating for a version management system in accordance with an exemplary embodiment;

fig. 2 is a block diagram showing a configuration of a rights updating apparatus of a version management system according to an exemplary embodiment;

fig. 3 is a block diagram illustrating a rights updating apparatus of a version management system according to another exemplary embodiment.

Detailed Description

In order to make the technical solutions of the present disclosure better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in sequences other than those illustrated or otherwise described herein. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

As described above, for a project jointly developed by dozens of users (developers) and even hundreds of users, a version management system may encounter a scenario where a rights management policy is frequently changed, and if a manager of the version management system is centralized to modify a rights configuration file for rights management, the efficiency of rights management may be low.

Fig. 1 is a flowchart illustrating a rights updating method 100 of a version management system according to an exemplary embodiment, and as shown in fig. 1, the rights updating method 100 of the version management system may be used in a server, and includes the following steps.

In step S102, when an authority update command of a version management system is received, a first version number of the authority update command is generated, where the authority update command is used to request that an authority configuration file of the version management system is updated by using authority files stored in various directories of the version management system.

Alternatively, the authority update command may be a commit command of the version management system, i.e., a command indicating an operation to perform a code update of the version management system.

Alternatively, the commit command may be triggered by the client user. In one example, the client is configured with a commit button, and a commit command can be issued to the server by clicking the commit button after locally updating the code of the version management system, wherein the commit command is used for triggering the server to execute the operation of updating the code.

The SVN is provided with a post-submission (post-commit) script, which is a hook function, and may update data in a version library of the version management system according to a code of a client user locally updating the version management system, and synchronize the data in the version library to a website directory, so that, in one example, after receiving a commit command, the content of the post-commit script, that is, an operation of performing a code update, may be executed.

In the embodiment of the present disclosure, the first version number of the permission update command may be the number of times of currently receiving the permission update command, for example, a global variable N may be maintained, and the variable N is incremented by 1 each time the permission update command is received. Of course, in practical applications, the version number of the permission update command may be a version number dedicated to recording the permission update command instead of the number of times the permission update command is currently received, and the version number is updated once each time the permission update command is received, and the specific form is not limited in this embodiment.

In step S104, an operation of locking a lock file is performed, where the lock file is used to maintain the version number of the permission update command.

In the embodiment, when the permission updating command is received, the locking operation on the lock file is executed, and if the locking is successful, other processes cannot operate on the lock file. The lock file can record the version number of the permission updating command when the permission updating is executed last time. I.e. the lock file is used to maintain the version number of the rights update command.

In step S106, if the lock file is successfully locked, a second version number of the permission update command stored in the lock file is read.

In a possible implementation manner, if the locking of the lock file fails, it indicates that a process is currently executing the permission updating operation, and therefore, the locking of the lock file is attempted again after waiting for a preset time duration, and if the locking is successful, the step of reading the second version number stored in the lock file is executed.

In step S108, if the second version number is smaller than the first version number, the first version number is written into the lock file to replace the second version number, the account identifier recorded in the authority file stored in each directory of the version management system is read, and in the authority configuration file, the account identifier having the control authority of each directory is updated to the account identifier read from the authority file in the directory, so as to update the authority configuration file.

In this embodiment, if the second version number is smaller than the first version number, it indicates that the update time of the rights file read by the last update rights configuration file is before the rights update command in step S102 is received, and therefore, the rights update operation can be performed.

This embodiment considers that updating the rights configuration file with multiple rights files in S108 requires a certain processing time T, while within the processing time T there may be multiple client users modifying the rights file and submitting (commit) to the server. However, the post commit mechanism in the server is operated once after each commit, and therefore, a process of updating the authority configuration file (auth. conf) multiple times may be triggered within the time T, and if such a process is out of order, a situation that a new authority configuration is covered by an old authority configuration occurs, resulting in confusion of configuration management.

Therefore, in this embodiment, the version number of the permission update command is maintained by the lock file, the lock file is locked before the permission configuration file is updated, if the locking is successful, the permission update operation is executed, and the current first version number is used to update the second version number in the lock file, that is, the version number of the permission update command in the lock file is updated to the first version number, so that the update sequence of the permission configuration file can be ensured, and the situation that a new permission configuration is covered by an old permission configuration is avoided.

In one possible implementation, if the second version number is greater than the first version number, the lock file is released without performing an update of the rights configuration file.

In one possible implementation manner, after the updating the account identifier having the control authority of each directory to the account identifier read from the authority file under the directory, the method further includes: and releasing the lock file. Through the possible implementation mode, after the updating of the authority configuration file is executed, the lock file is released, so that the lock file can be locked again when the authority updating command is received next time.

In one possible implementation manner, when the update of the authority configuration file is performed, the following steps may be included:

step S12, obtaining an authority file, where the authority file is located under a target directory, and at least one first account identifier having a control authority of the target directory is recorded in the authority file.

In a possible implementation manner, a permission file may be created under each directory under the version management system, and the account identifier having the control permission corresponding to the target directory is recorded by the permission file. In step S12, the rights files under the respective directories are acquired.

In one example, the rights file may include a plurality of rights files, i.e., the rights file is included under each of a plurality of target directories of the version management system. For example, a first right file is included in the first directory, and user identifications D and E are recorded in the first right file; a second authority file is included in the second directory, and a user identifier F is recorded in the second authority file; a third authority file is included in the third directory, and user identifications G and H are recorded in the third authority file; and the like. Therefore, the number of the rights files that can be acquired in step S102 is plural, for example, all the rights files such as the first rights file, the second rights file, and the third rights file are acquired.

Optionally, the step may use a traversal mode to traverse all directories of the version management system to obtain each permission file.

Step S14, reading the at least one first account identifier in the rights file.

In one possible implementation, step S12 may be performed after receiving the permission update command (i.e., step S102).

In one possible implementation, upon receiving the permission update command, it may be determined whether the permission file is updated, and if so, step S14 is executed, and if not, the next permission update command may be waited to save the process. Therefore, in this possible implementation, before step S14, the method may further include: and judging whether the information recorded in the current authority file is the same as the information recorded in the authority file when the authority updating command is received last time, and if so, executing the step S14.

For example, after receiving a commit (commit) command, a code update is performed, in the process of which it is possible to detect whether the rights file is updated. It can be determined whether the content of the rights file has been changed during execution of the post-commit script. For example, whether a user identifier is added to the authority file or not, whether a user identifier is decreased or not, and the like are detected.

The first user identification(s) in the rights file have operating rights to the target directory. It will be appreciated that the target directory may include a number of other files, such as a repository file for storing code, in addition to the rights file described above. Moreover, there may be sub-directories under the target directory, so the operation authority for the target directory mentioned in this embodiment includes not only the operation authority for the authority file (because the authority file is located under the target directory), but also the operation authority for other files besides the authority file under the target directory and the authority file under the sub-directories thereof. The operation rights mentioned in this embodiment are, for example, rights of addition, deletion, modification, viewing, and the like.

In one example, the target directory is a root directory, and a rights file (i.e., an owner file) is included under the root directory, and the owner file includes three user identifications recorded therein: A. b and C, the information expressed by the owner file is that A, B, C three users have the operation authority of the root directory, that is, A, B and C three users can add new user identifications in the owner file, and certainly delete existing user identifications; A. the three users B and C may also have operation rights (e.g., change, delete rights, etc.) to other files in the root directory and its subdirectories.

Step S16, in the authority configuration file of the version management system, updating the account identifier having the control authority of the target directory to the read at least one first account identifier, so that the user of the at least one first account identifier has the control authority of the target directory. That is, in step S16, the read authority file updates the authority configuration file of the version management system.

It will be appreciated that the rights configuration file of the version management system may comprise all rights information of the version management system, e.g. the rights configuration file of the version management system comprises a plurality of user identities, and for which directory(s) of (each of) the plurality of user identities has rights (add, delete, etc.) to, etc.

In a possible implementation manner, in step S16, a new permission configuration file may be generated, the account identifier having the control permission of the target directory is recorded in the new permission configuration file as the read at least one first account identifier, and then the current permission configuration file of the version management system is replaced by the new permission configuration file. Through the possible implementation mode, the completeness of the authority configuration can be guaranteed when the authority configuration file is updated.

In one possible implementation manner, the account id having the control authority of a certain target directory may perform a control operation on the authority file under the target directory. Thus, in this possible implementation, the method may further include: receiving a first operation command for indicating control operation on the authority file, wherein the first operation command carries a second account identifier; and searching the second account identifier in the permission configuration file, and if the second account identifier is searched and the second account identifier is recorded in the permission configuration file to have the control permission of the target directory, executing the control operation corresponding to the first operation command on the permission file. For example, at least one of the first account identifications is added or deleted in the rights file.

In a possible implementation manner, after step S16, the first account identifier has a control authority of the target directory, and may perform a control operation on the target directory and files under the subdirectories of the target directory. Thus, in this possible implementation, the method may further include: receiving a second operation command from a first client, wherein the first client logs in the version management system by using the first account identifier, the second operation command indicates that a control operation is performed on a target file, and the target file comprises: files under the target directory and/or files under subdirectories under the target directory; and executing the control operation corresponding to the second operation command on the target file. In a specific application, when a second operation command is received, whether a first account identifier for sending the second operation command is recorded in an authority configuration file of the version management system may be searched, if so, whether the first account identifier has a control authority of the target directory may be further determined, and if so, a control operation corresponding to the second operation command is executed, for example, a target file is newly created, a target file is modified, a target file is deleted, or a target file is checked.

In the embodiment of the present disclosure, if the control authority of a certain target directory needs to be modified, a user having the control authority of the target directory may modify a authority file under the target directory, and record at least one first account identifier having the control authority of the target directory in the authority file. For example, in one possible implementation, before step S12, the method may include: receiving a third operation command from a second client, wherein the second client logs in the version management system by using an administrator identification of the version management system, the third operation command indicates that the authority file is created under the target directory, and the target directory comprises: a root target of the version management system; creating the authority file and recording the at least one first account identifier in the authority file, wherein the at least one first account identifier comprises: the administrator identification. In this possible implementation manner, an administrator of the version management system may log in the version management system using the administrator identifier, create a permission file under a root directory of the version management system, and record at least one first account identifier in the permission file, that is, grant permission for the at least one first account identifier to operate the root directory, so that the at least one first account identifier may create or modify the permission file under the root directory and its respective sub-directories.

According to the authority updating method of the version management system, the authority file is added under the target directory, at least one first account identifier with the control authority of the target directory is recorded in the authority file, the at least one first account identifier is read from the authority file, then the account identifier with the control authority of the target directory is updated to the read at least one first account identifier in the authority configuration file of the version management system, and therefore the user of the at least one first account identifier has the control authority of the target directory. Therefore, the authority of the target directory can be maintained by the user who already has the authority of the target directory, so that the pressure of a system administrator is shared, and the authority management efficiency of the version management system is improved. In addition, the problem of configuration management confusion caused by the fact that a new authority configuration file is covered by an old authority configuration file can be avoided by locking the version number of the file maintenance authority updating command.

To describe the rights management method of the version management system provided in the present disclosure in detail, the SVN system will be described as an example.

The embodiment of the present disclosure realizes the control of the access authority of the SVN directory by modifying a certain file content (i.e. the user identifier in the aforementioned target authority file) in the SVN code repository, and there are three problems here:

the first problem is how the file content expresses the rights information. Resources in the SVN code repository are organized in directories and files, so setting an access right is actually specifying what user can do under what directory. Two elements are mainly involved here: user, directory. The disclosed embodiment expresses this information using a file named owner (i.e., a rights file) whose contents are a list of users, each user name occupying a row. The directory to which the owner file belongs is the directory to which the authority information is to be set, so that the information of the user and the directory can express an authority configuration, that is, the owner file in each SVN can completely express an authority information.

For example, a owner file is created under the root directory, and the file contents are:

A

B

C

then the information that this owner file can express is A, B, C the rights of three users to have the root directory.

The second problem is how to translate the information of the owner file into the content of the rights configuration file auth. Because the owner file is also within the SVN repository, changes to the contents of the owner file are ultimately committed to the SVN server using a commit (commit) command.

The SVN provides a post-commit (post-commit) script, and the SVN server executes the content of the post-commit script after each commit, so that the embodiment may determine whether the commit involves an owner file content change in the post-commit script, if so, may traverse all directories of the SVN to obtain each owner file, and reconstruct a new file auth. And after the reconstruction process is finished, replacing the original auth.

A third problem is how a user who already has a right maintains the right. Because users who already have a certain directory right can see and update the owner file under the directory, the users can complete the right management under the directory by themselves by changing the owner file and committing the content of the file.

A generally large SVN code repository may be divided into several large subdirectories at the root directory level, and then an SVN administrator may add an owner file to the root directory and write its own user name in the owner file of the root directory. Then, the owner files are respectively added in the large subdirectories, and the users who want to bear the management authority are respectively added in the owner files, so that the authority management under the current subdirectory can be self-completed by other users who already have the authority, and only when a new subdirectory needs to be added in the root directory, the SVN administrator needs to perform initialization operation.

For example, an SVN code repository directory structure is such that:

thus, rights management after/abc and/def directories can be done by a and B respectively, if a new directory ghi needs to be added/down, then an administrator is required to create the new directory and at the same time create an owner file to specify who owns the rights of the new directory.

The SVN authority management method provided by the present disclosure: the user who has the authority can bear the responsibility of maintaining the authority of the directory where the user is located, the pressure of an administrator is shared, and the large project can be more easily supported to be smoothly developed; the owner file is convenient for users who have authority to check and modify, and can check the owner file at any time to know the authority setting information of the current system; the owner file uses the version control capability of the svn because of being submitted to the code warehouse, so that users and specific contents of each change can be accurately known, and the change of the authority information can be audited conveniently to confirm the reasonability of the authority change.

The embodiment adds the owner file to different directories in the SVN code repository to describe the authority control of the directory, and after updating the owner file and commit to the SVN server each time, the SVN server scans all the owner files through the post-commit mechanism to reconstruct the authority configuration file auth. This may cause a problem in that reconstructing an auth. conf with the contents of the owner file requires a certain computation time T, and then there may be multiple changes committed to the SVN server that modify the owner file within T time. The Post-commit mechanism is operated once after commit, so that a process of rebuilding auth.conf for many times may be triggered within the time T, and if the process is out of order, a situation that a new authority configuration is covered by an old authority configuration may occur, so that configuration management may be confused.

In order to avoid the new authority configuration being covered by the old authority configuration, the embodiment of the present disclosure adopts the following scheme: in a post-commit script triggered to be executed after commit each time, a linux file lock function is used, and a lock file lock is used to ensure that post-commit running at the same time is changed from parallel execution to serial execution, and the method specifically comprises the following steps:

1. file is locked first every time the post-commit execution attempts to lock;

2. file is found to be locked by other processes, waiting for 10 seconds in place and then trying to lock again;

3. and if the lock of the lock.file is successful, firstly reading the file content in the lock.file, wherein the lock.file stores a commit version number T corresponding to the last-commit execution process which is successful in locking last time.

3.1 if the T is greater than the commit version number T1 corresponding to the current post-commit executing process, it indicates that the post-commit process of the higher version has already been executed, and the processing procedure of the current lower version is not required to be continuously executed, so the lock.

Since the higher version of the post-commit procedure is executed to update the rights configuration file based on the full amount of the owner file, the low version of the post-commit is not required to execute the operation of updating the rights configuration file.

3.2 if T is less than or equal to T1, then T1 is written to the lock. The process in post-commit continues to execute, generating auth.

4. And exiting after the execution is finished.

File realizes that the concurrent post-commit process is changed into serial execution, and version number information in the lock file ensures that low-version data cannot cover high-version data, thereby avoiding new authority configuration from being covered by old authority configuration.

The embodiment of the disclosure can avoid the code safety problem caused by the bad writing of the authority configuration file, and reduce the maintenance cost of the daily svn. Meanwhile, the file lock is used for ensuring the post-commit to execute in series; and the version number in the file lock is used for ensuring that the low-version data cannot cover the high-version data.

The SVN authority management method provided by the embodiment uses the basic capability combination of the existing SVN to realize the scheme, so that the practicability is high, and the development cost is low; the authority configuration information of the code warehouse is managed in a code mode, and the code authority and the authority for managing the code authority are unified together, so that the understanding and the operation are convenient.

The rights updating method of the version management system according to the embodiment of the present invention is described in detail above with reference to fig. 1. The rights updating apparatus of the version management system according to another embodiment of the present invention will be described in detail with reference to fig. 2.

Fig. 2 is a block diagram illustrating a rights updating apparatus 200 of a version management system according to an exemplary embodiment, where the apparatus 200 corresponds to the server mentioned in the foregoing embodiments. Referring to fig. 2, the apparatus 200 includes a code generating unit 202, a control unit 204, a reading unit 206, and an updating unit 208.

In this embodiment, the generating unit 202 is configured to generate a first version number of a permission update command when receiving the permission update command of a version management system, wherein the permission update command is used for requesting to update a permission configuration file of the version management system by using permission files stored under various directories of the version management system; a control unit 204 configured to perform an operation of locking a lock file, wherein the lock file is used for maintaining the version number of the permission update command; a reading unit 206, configured to execute, if the locking of the lock file is successful, reading a second version number of the permission update command stored in the lock file; an updating unit 208 configured to execute, if the second version number is smaller than the first version number, writing the first version number into the lock file to replace the second version number, and reading the account identifier recorded in the authority file stored under each directory of the version management system, and in the authority configuration file, updating the account identifier having the control authority of each directory to the account identifier read from the authority file under the directory, so as to update the authority configuration file.

Optionally, the control unit 204 is further configured to perform: and after the account identification with the control authority of each directory is updated to the account identification read from the authority file under the directory, releasing the lock file.

Optionally, the updating unit 208 updates the account identifier having the control authority of each directory to the account identifier read from the authority file under the directory, including:

Optionally, the control unit 204 is further configured to perform: if the locking of the locked file fails, the target file is tried to be locked again after waiting for a preset time, and if the locking is successful, the reading unit 206 is triggered to read the second version number stored in the locked file.

Optionally, the control unit 204 is further configured to release the lock file if the second version number is greater than the first version number.

In the rights updating apparatus of the version management system provided by the present disclosure, the generating unit 202, upon receiving a rights updating command of the version management system, generates the first version number of the permission update command, the control unit 204 performs the operation of locking the lock file, and if the locking of the lock file is successful, the reading unit 206 is triggered to read the second version number of the authority update command stored in the lock file, if the second version number is less than the first version number, the update unit 208 writes the first version number to the lock file to replace the second version number, and reads the account id recorded in the authority file stored under each directory of the version management system, and updating the account identification with the control authority of each directory into the account identification read from the authority file under the directory in the authority configuration file, so as to realize the updating of the authority configuration file. Therefore, the authority configuration file of the version management system can be updated through the updated target authority file. Therefore, the user who already has the authority of the target directory can bear the responsibility of maintaining the authority of the target directory, the pressure of an administrator of the version management system is shared, the authority management efficiency of the version management system is further improved, and the smooth development of large projects is easier to support.

In addition, the problem of configuration management confusion caused by the fact that a new authority configuration file is covered by an old authority configuration file can be avoided by locking the version number of the file maintenance authority updating command.

Fig. 3 is a block diagram illustrating a rights updating apparatus 300 for a version management system according to an exemplary embodiment. The authority update 300 of the S version management system corresponds to the server mentioned in the embodiment 100.

The apparatus 300 may be provided as a server. Referring to FIG. 3, apparatus 300 includes a processing component 322 that further includes one or more processors and memory resources, represented by memory 332, for storing instructions, such as applications, that are executable by processing component 322. The application programs stored in memory 332 may include one or more modules that each correspond to a set of instructions. Further, the processing component 322 is configured to execute instructions to perform the method 100 described above.

The apparatus 300 may also include a power component 326 configured to perform power management of the apparatus 300, a wired or wireless network interface 350 configured to connect the apparatus 300 to a network, and an input/output (I/O) interface 358. The apparatus 300 may operate based on an operating system stored in the memory 332, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, or the like.

In an exemplary embodiment, there is also provided a storage medium, such as a memory, including instructions executable by a processor of a rights update apparatus of a version management system to perform the SVN rights management method described above. Alternatively, the storage medium may be a non-transitory computer readable storage medium, which may be, for example, a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

It should be noted that, since the permission updating method of the version management system executed by the apparatus 300 in this embodiment has the same or corresponding technical features as the permission updating method of the version management system in the foregoing embodiment 100, the detailed description of the permission updating method of the version management system in this embodiment may refer to the description of the permission updating method of the version management system in the foregoing embodiment 100, and the description of this embodiment is not repeated herein.

In an exemplary embodiment, a computer program product is also provided that includes at least one non-transitory computer readable medium storing instructions translatable by at least one processor for implementing the aforementioned method 100 of rights updating for a version management system.

It should be noted that, since the permission updating method of the version management system implemented by the computer program product in this embodiment has the same or corresponding technical features as the permission updating method of the version management system in the foregoing embodiment 100, the detailed description of the permission updating method of the version management system in this embodiment may refer to the description of the permission updating method of the version management system in the foregoing embodiment 100, and the description of this embodiment is not repeated here.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for updating rights of a version management system, comprising:

2. The method of claim 1, wherein after updating the account id having the control authority of each directory to the account id read from the authority file under the directory, the method further comprises:

and releasing the lock file.

3. The method of claim 1, wherein updating the account id having the control authority of each directory to the account id read from the authority file under the directory comprises:

4. The method of claim 1, wherein if locking the lock file fails, the method further comprises:

and locking the lock file again after waiting for a preset time, and if the locking is successful, executing the step of reading the second version number stored in the lock file.

5. The method of claim 1, wherein if the second version number is greater than the first version number, the method further comprises:

and releasing the lock file.

6. The method according to any one of claims 1 to 5, wherein the rights update command comprises: an upload command of a code file of the version management system.

7. An authority updating apparatus of a version management system, comprising:

8. The apparatus of claim 7, wherein the control unit is further configured to perform: and after the account identification with the control authority of each directory is updated to the account identification read from the authority file under the directory, releasing the lock file.

9. An authority updating apparatus of a version management system, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the rights updating method of the version management system of any of claims 1 to 6.

10. A storage medium in which instructions, when executed by a processor of an authority updating apparatus of a version management system, enable the authority updating apparatus of the version management system to perform the authority updating method of the version management system according to any one of claims 1 to 6.