Patent Application
20120131553
1. Technical Field
The disclosure generally relates to a source code file management system and a source code file management method.
2. Description of Related Art
Source code is a sequence of statements that is usually written in a high level programming language, such as, without limitation, C programming language, C++, or Java™. Source code is usually stored in one or more text files until the code is compiled and executed. As a program is designed and developed, frequently multiple versions of the same program are often deployed at different sites for utilization by multiple program developers. In such a case, a source code file is often edited by members of a team. The team members may be in different physical locations and they may apply updates to the source code without team consultation. In such situations, version control systems are frequently used to track and account for ownership of updates and changes to files and code. However these version control systems do not investigate the source code file before the source code file is committed to a source code repository. Therefore there is room for improvement in source code file management.
Many aspects of the embodiments can be better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale, the emphasis instead being placed upon clearly illustrating the principles of the embodiments. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.
The disclosure is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
In general, the word “module”, as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, written in a programming language, such as, Java, C, or assembly. One or more software instructions in the modules may be embedded in firmware, such as in an EPROM. The modules described herein may be implemented as either software and/or hardware modules and may be stored in any type of non-transitory computer-readable medium or other storage device. Some non-limiting examples of non-transitory computer-readable media include CDs, DVDs, BLU-RAY, flash memory, and hard disk drives.
In one embodiment, the storage system 110 may be a magnetic or an optical storage system, such as a hard disk drive, an optical drive, or a tape drive. The storage system 110 may allocate space for a source code storage (not shown). The source code storage is a repository where current and historical files associated with source code is stored. A source code file stored in the source code storage may be associated with a unique version number that identifies the source code file.
The network adapter 130 may be a network interface card using a specific physical layer and a data link layer standard such as Ethernet or Wi-Fi. The network 40 may be a local area network (LAN), or a wide area network (WAN), such as the Internet.
The developer client 20 represents a developer in a multi-developer project. The developer can utilize the developer client 20 to submit a commit request and a source code file to the source code file management system 100. The examiner client 30 represents an examiner who is responsible for examining the source code file submitted by a developer. The source code file management system 100 may communicate with multiple developer clients 20 and multiple examiner clients 30.
The storage system 110 may allocate space for a profile storage (not shown). The profile storage may store a developer profile for every developer. In
The first receiving module 101 may receive a source code file from a developer client 20.
The generating module 102 may generate an intermediate file based on the source code file. The generating module 102 may check whether there is an older version of the source code file in the source code storage. When there is not an older version of the source code file in the source code storage, the generating module 102 can copy the content of the source code file into the intermediate file. When there is an older version of the source code file (older version) in the source code storage, the generating module 102 may further check whether the older version is in all respects the same as the source code file. If the older version is in all respects the same as the source code file, the generating module 102 can instruct the message module 108 to send a rejection message to the developer client 20. The rejection message notifies the developer that the source code file is rejected because there the same file already exists in the source code storage. If the older version is different from the source code file, the generating module 102 can copy the contents of both the source code file and the older version into the intermediate file, and record the difference(s) between the source code file and the older version in the intermediate file.
In one embodiment, the generating module 102 may calculate a check code for both the older version and the source code file. The check code is a cyclic redundancy check (CRC) code or a message digest 5 (MD5) code. In this embodiment, the generating module 102 may check whether the source code file is the same as the older version by comparing the check code of the source code file against the check code of the older version.
The retrieving module 103 may retrieve a developer profile associated with the developer from the profile storage. The determining module 104 may determine a plurality of examiners according to the developer profile. For example, the retrieving module 103 retrieves the developer profile 301 shown in
The transmitting module 105 may establish a priority sequence in relation to the plurality of examiners (examiner sequence) according to the priority rank of each of the plurality of examiners and transmit the source code file to the plurality of examiner clients in the examiner sequence. In
The second receiving module 106 may receive a plurality of examining results from the plurality of examiner clients. When every examining result is accepted, the storing module 107 can store the source code file in the source code storage as requested. When one of the plurality of examining results is rejected, the message module 108 may send a rejection message to the developer client.
In step S401, the first receiving module 101 receives a source code file from a developer client associated with a developer.
In step S402, the generating module 102 generates an intermediate file based on the source code file.
In step S403, the retrieving module 103 retrieves a developer profile associated with the developer from the profile storage.
In step S404, the determining module 104 determines a plurality of examiners according to the developer profile.
In step S405, the transmitting module 105 establishes an examiner sequence according to the priority rank of each of the plurality of examiners and transmits the source code file to the plurality of examiner clients in the examiner sequence.
In step S406, the second receiving module 106 receives a plurality of examining results from the plurality of examiner clients.
In step S407, if every examining result is accepted, the flow goes to step S408. If one of the plurality of examining results is rejected, the flow goes to step S409.
In step S408, the storing module 107 stores the source code file in the source code storage.
In step S409, the message module 108 sends a rejection message to the developer client.
In step S501, the generating module 102 copies the content of the source code file into the intermediate file.
In step S502, the generating module 102 checks whether there is an older version of the source code file in the source code storage. If there is not an older version of the source code file in the source code storage, the flow goes to step S507. If there is an older version of the source code file in the source code storage, the flow goes to step S503.
In step S503, the generating module 102 copies the content of the older version into the intermediate file.
In step S504, the generating module 102 checks whether the older version is the same as the source code file. If the older version is the same as the source code file, the flow goes to step S505. If the older version is different from the source code file, the flow goes to step S506.
In step S505, the generating module 102 instructs the message module 108 to send a rejection message to the developer client.
In step S506, the generating module 102 records the difference(s) between the source code file and the older version in the intermediate file.
In step S507, the generating module 102 provides the intermediate file to the transmitting module 105.
It is to be understood, however, that even though numerous characteristics and advantages have been set forth in the foregoing description of embodiments, together with details of the structures and functions of the embodiments, the disclosure is illustrative only and changes may be made in detail, especially in matters of shape, size, and arrangement of parts within the principles of the disclosure to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.
Depending on the embodiment, certain steps or methods described may be removed, others may be added, and the sequence of steps may be altered. It is also to be understood that the description and the claims drawn for or in relation to a method may include some indication in reference to certain steps. However, any indication used is only to be viewed for identification purposes and not as a suggestion as to an order for the steps.
| Number | Date | Country | Kind |
|---|---|---|---|
| 99140463 | Nov 2010 | TW | national |
