ONLINE HELP
 WINDEVWEBDEV AND WINDEV MOBILE

This content has been translated automatically.  Click here  to view the French version.
Help / Developing an application or website / SCM (Source Code Manager)
  • Overview
  • How to?
  • Defining a check-in policy
  • How the check-in policy works
  • Storing and handling the check-in policy
  • Details of the different rules
  • "General" tab
  • "Automated tests" tab
  • "Code metrics" tab
  • "Action plan" tab
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadIOS WidgetApple WatchMac CatalystUniversal Windows 10 App
Others
Stored procedures
Overview
The SCM gives you the ability to define a check-in policy. Simply define the criteria that must be matched in order for a project element to be checked back in into the repository. Among the possible criteria:
  • No compilation error,
  • Launch at least one element test, etc.
These rules can be mandatory or not. If a rule is not complied with, the developer may be required to provide an explanation.
How to?

Defining a check-in policy

To define a check-in policy:
  1. On the "SCM" tab, in the "Repository" group, expand "Manage" and select "Check-in policy".
    SCM check-in policy
  2. Select the conditions the checked-in elements must meet. These rules are grouped in three tabs: "General", "Automated tests" and "Code metrics".
  3. Specify the options of the check-in policy:
    • Always ignore the rules on the project (wdp): Used to ignore the rules when handling the project file (wdp file).
    • Ability to ignore the rules.
    • Required comment if a condition isn't met.
  4. Validate. The check-in policy is automatically taken into account for the current project.
Remark: The check-in policy can also be defined from the SCM administrator ("Check-in policy" from the popup menu of a project).

How the check-in policy works

If the reintegrated element does not comply with the reintegration policy defined for the project:
  • if an comment is required, an toast is displayed.
  • if one of the other rules is not respected, the following window appears:
    This window shows the various rules that have not been respected..
If users are allowed to ignore the rules, they can check "Check in anyway".
If an explanatory comment must be entered to ignore the rules, the validation button in this window will only be cleared when the comment is entered in the corresponding field.
The "Edit the policy" button allows you to edit and modify (if necessary) the rules defined for the check-in policy.

Storing and handling the check-in policy

The check-in policy is stored in the "CheckInPolicy.scm" file found at the root of the project directory. This file is located in the SCM as all the project files. This file can be shared among several projects.
Specific rights can be assigned to the file corresponding to the check-in policy (to allow the project manager to modify this file for example).
If the "CheckInPolicy.scm" file is found in the parent directory, all the newly created projects will use this check-in policy.
Tip: For a branch, you have the ability to define a more restrictive check-in policy.
Details of the different rules

"General" tab

The different check-in rules proposed by the "General" tab are:
  • No compilation error: To be checked in, the element must include no compilation errors.
  • No compilation warning: To be checked in, the element must include no compilation warnings.
  • No compilation information: To be checked in, the element must include no compilation information.
  • No programming standard errors: To be checked in, the element must include no programming standard errors. This programming standard is defined in the "Compilation" tab of the project description window. For more details, see Project description: Compilation tab.
  • The checked-in element must be associated with a task or with an incident.
  • A comment must be entered during the check-in operation.
  • The project test (GO) must have been run at least once after a modification.

"Automated tests" tab

The check-in rules proposed by the "Automated tests" tab are:
  • Each element must include at least 1 automated test. Caution: if this option is selected, it applies to all the elements, even to the project file (".WDP") that contains the project initialization code.
  • No automated test with errors.

"Code metrics" tab

The "Code metrics" tab is used to enter the minimum percentage level to respect for code comments.

"Action plan" tab

In this tab, you can define the action plan to be executed when the project is checked in. If an action plan is to be executed, specify:
  • the software factory coordinator,
  • the port of the coordinator,
  • the user and the associated password.
You can choose from the existing plans in the coordinator.
Minimum version required
  • Version 12
This page is also available for…
Comments
Click [Add] to post a comment

Last update: 04/27/2024

Send a report | Local help