Fernando Carbonero. EcosimPro Development Team
EcosimPro provides source code control for ASCII files used inside the tool (additional files, ASCIIs or binaries, could be added by using a “miscellaneous files window”). This feature will be supported both functionally and graphically. It is assumed that the user has installed a SubVersion (SVN) repository to connect to, that is to say, EcosimPro cannot create or administer the repository.
A source code control is a system for controlling changes in files and for arbitrating how those files are to be shared. It is generally meant for ASCII files, since it can be used to control and compare the differences between the various different versions. This does not mean that it cannot be used with binary files, but it does mean that it can only identify if the file has been changed or not, but not the differences between the versions.
Each user works with an independent local copy. When changes must be shared (or simply stored for control purposes) they will be uploaded to a repository. A repository is a data base that stores files with all their modifications throughout the project. Text files are not stored as such in the repository, but rather, they are stored in compressed form. Furthermore, if a file is modified, the new file is not stored as a whole, but rather, only the changed part is stored. This way, the repository can house a large amount of information by optimising the available storage space. This optimisation is not possible with binary files, since binary files do require the entire file to be stored after each modification.
Each time a change is uploaded to the repository, it is marked with a number. Each change is called a revision. A revision is comparable to a snapshot of the entire project at a given time. In other words, a revision is a global number that belongs to all the files, not only to the one(s) on which the change was made.
In principle, only the files created by the user should be uploaded to the repository, and not the ones generated by EcosimPro, i.e., the ASCII files of source code, setup files, input data files, partitions, experiments, schematics, etc. as well as binary files such as .lib files for external libraries, etc. The files generated as .elb, .unt, .dll, etc. should not be uploaded.
The ASCII files are not only for finding differences, but also, when two users modify the same code at the same time, mechanisms are set to detect and correct any conflicts. This is not possible in binary files.
The uploaded elements should be as needed to generate the rest of the files again. EcosimPro will only handle these source files, although there is an option for uploading other file types. Thus, when a library is uploaded to a repository, it is advisable to do so using EcosimPro rather than an outside tool to prevent uploading files that may cause problems.
Integration in current widgets
The configuration manager integrates into EcosimPro using an extension of current icons with an area in which the file status will be presented. This status represents the relationship between the local file or path and the one in the repository. Colour icons have been designed to show the different statuses.
Local file status related to repository
SVN has a great number of statuses available, but only the ones considered as relevant to EcosimPro have been implemented. The proposed status set, with icons associated to each status is as follows:
File has not been modified in local version
File has been modified in local version
File has been set to be added to the repository on commit action
File has been set to be deleted from the repository on commit action
There is a conflict between the local file and repository
Local file is not in the repository
Local file is not in the repository and it is ignored (from the point of view of configuration manager)
Tool configuration is pointing to a file which is not on the local disk
The item has several associated elements with different statuses
Source Code Control actions
As in the case of status, SVN has a great number of actions available. Again, only the ones considered relevant to EcosimPro have been implemented. The actions available for each file will depend on its status. Only the actions that are available will be shown in the menus, so as to simplify the way that SCC actions are presented to the user. These actions will be divided into two groups: the most common actions will be shown in the context menu of the file, while the less common actions will be in an SCC submenu.
The set of available actions is as follows:
- Connect to repo: Connect a workspace file or library to the repository.
- Commit: Upload a set of changes in one or more files to the repository as a unique revision.
- Revert: Revert an action on a file or path.
- Diff: Show the difference between the local and repository version.
- Show log: Show log dialog of a file or path. This log contains a list of revisions in which changes have been made involving the file or path. Each revision has information such as the changes made, how the changes were made, who made the changes, when the description of the change was made, etc.
- Launch browser: Launch browser in repository path associated to pointed file or path.
- Check for modifications: Check if other users have uploaded any modification.
- Update: Update current file or folder. This action brings up locally the changes that the other users have made merging with their files. The changes made locally on the same files will be maintained. The repository is not affected by an update. If a conflict arises when an update is carried out, two steps must be taken: edit the conflict and then mark it as resolved. A conflict is understood to be the following:
- File conflict: changes have been made locally to the same lines as another user, and the other user has loaded it to the repository
- Tree conflict: when a user adds, renames or deletes files and another user has also added, renamed or deleted them or modified and loaded them to the repository
- Edit conflicts: If, after updating, conflicts in a file arise, the system will create some extra files that contain the different versions and will add marks to the user’s local file to show where the file is. Although it could be edited by hand textually, TortoiseSVN has a tool to merge the two versions graphically, ie to select the valid version. Once the problems have been resolved, the user must confirm the action via Resolve conflicts.
- Resolve conflicts: Confirms that the conflicts generated by an update have been resolved. If this action is run without solving the conflicts, the file with the conflict will be wrong when it is uploaded to the repository because it will include the markings used to indicate the conflict and the two proposals to solve it (the local one and the one in the repository). This action will be allowed only when there is a conflict, except in the pop-up menu of a library directory, where it will always be available to solve the tree conflicts.
- Add: Set a file as new one in repository after commit action.
- Delete: Set a file as deleted in repository after commit action.
- Ignore: Set a file as ignored. This prevents the file from being treated as unversioned, that is, it can be added to the repository.
- Clean up: Eliminate a potential inconsistent status of the local copy of the directory in a library. This status can be caused by a Subversion command not being correctly completed, possibly because of server issues. This option is only available in the pop-up menu of a library directory.