SCM: Check-in policy

ONLINE HELP
WINDEV, WEBDEV AND WINDEV MOBILE

Version:

Home | Sign in | English

Overview
How to proceed?
Defining a check-in policy
Operating mode of check-in policy
Storing and handling the check-in policy
Details of the different rules
"General" tab
"Automatic tests" tab
"Code metrics" tab

WINDEV

WEBDEV

WINDEV Mobile

Others

See also

SCM: Check-in policy

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,
Run at least one test of the element, ...

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 proceed?

Defining a check-in policy

To define a check-in policy:

On the "SCM" pane, in the "Repository" group, expand "Manage" and select "Check-in policy".
Select the rules that must be respected by the checked-in elements. These rules are grouped in three tabs: "General", "Automatic tests" and "Code metrics".
Specify the options of the check-in policy:
- Versions 19 and later
  Always ignore the rules on the project (wdp): Used to ignore the rules when handling the project file (wdp file).
  New in version 19
  Always ignore the rules on the project (wdp): Used to ignore the rules when handling the project file (wdp file).
  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.
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).

Operating mode of check-in policy

The following screen is displayed if the checked-in element does not comply with the check-in policy defined for the project:

This screen lists the criteria that are not fulfilled by the checked-in element.

If the user is allowed to ignored the rules, he has the ability to check "Check in anyway".

If an explanation must be entered, the validation button of this window will be ungrayed only when the comment is entered in the corresponding area.

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 found 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.
Versions 24 and later
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. See Project description: Compilation tab for more details.
New in version 24
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. See Project description: Compilation tab for more details.
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. See Project description: Compilation tab for more details.
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.

"Automatic tests" tab

The check-in rules proposed by the "Automatic tests" tab are:

Each element must include at least 1 automatic test. Caution: if this option is selected, it applies to all the elements, even to the project file (".WDP") that contains the initialization code of the project.
No automatic test in error.

"Code metrics" tab

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