Help / Developing an application or website / Source Code Manager (SCM)
  • Overview
  • Before changing version
  • When changing version
  • The change of version
  • Working with the branch
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WindowsLinuxPHPWEBDEV - Browser code
AndroidAndroid Widget iPhone/iPadIOS WidgetApple WatchMac CatalystUniversal Windows 10 App
Stored procedures
Changing the version of projects found in SCM
When several projects share elements in the same SCM, changing the version of WINDEV, WEBDEV and WINDEV Mobile projects must be done with great care.
When a project is opened in a later version of WINDEV, WEBDEV or WINDEV Mobile (e.g., version 24 to version 25), all its elements (windows, classes, etc.) are "converted" to the new format in order to take advantage of the new features of that version.
If some of these elements are shared with other projects via SCM, the other projects (still in earlier version, 24 for example) will not be able to retrieve the update of elements opened with a later version.
The local projects in version 24 can still operate but if they were not updated for a correction regarding an element opened with the later version, they will not be able to easily retrieve the corrections.
Before changing version
Write the full list of projects that share elements via the SCM: if you choose to open a project with a new version, all projects that share at least one element will have to be opened with this version at the same time.
For each shared element found in the "main" project, list all projects that share this element.
In the SCM administrator, a shared element can be identified by a specific pictogram.
To list the projects that share an element, from the SCM administrator, open the element properties (right mouse click, "Properties") and display the "Shares" pane.
This operation must be performed for each project that shares an element, in recursive way: if you open with a later version a project A that shares an element with a project B that shares another element with a project C, the 3 projects will have to change version at the same time.
Important: schedule a date to switch your projects to a later version! Switching a project containing shared elements to a later version must not be done with great care.
When changing version
The following operations must be performed:
  1. From the SCM administrator, make sure that all the elements of all relevant projects are properly checked back in: no element must be checked out before the change of version.
  2. Open the relevant projects in their current version (24 for example) and check whether all the local elements are updated.
    These checks are used to make sure that the backup branch that will be created later will contain all the elements in their most updated version.
    Furthermore, having a local version of project properly updated is a great benefit in case of problem.
The change of version
The change of version must be performed in a sequential way: a project then another one, and so on.
If you work as part of a team, don't change version simultaneously for the linked projects.
First of all, modify the project containing the greatest number of shared elements.
For each project:
  1. Open the project in the new version (25 for example): an SCM window is opened, indicating that you try to open a project created in an earlier version.
  2. Select "Switch this project to version 25 and keep the SCM connection" and don't forget to check "Create a branch in the SCM with the former project".
    Creating a branch is ESSENTIAL in most cases!
  3. In the branch creation wizard, keep the default branch name ("Backup version 24").
    If you modify the name of this branch, don't forget to apply the same branch name to all the projects.
    Naming the branch is essential in order for the shares of elements between projects to be properly re-applied within the branch.
  4. At step 3/3 of the branch creation wizard, check "Find and re-create the shares in the branch".
    If your local projects are updated, check "Use my local version as reference for the branch".
  5. Once the branch is created and the project opened in a later version, check all the checked-out project elements back in and close the project.
  6. In the SCM administrator, make sure that all the project elements have been checked back in.
  7. Don't forget to check that the branch containing the former project version ("Backup version 24") is still found.
This operation must be performed for all the affected projects.
Working with the branch
Once all the projects have changed version, you still have the ability to work on the former project version (version 24 for example) if necessary (urgent modification or correction for example).
To do so, simply open the project located in the branch:
  • if the migration was performed on your computer, the branch creation wizard automatically copied the project to "C:\My Projetcs.Branches\Backup version 24\" (default directory).
  • if the migration was performed on another computer or by another developer, select "Open a project from the SCM" and select the project in the "SCM:\\Branches\Backup version 24\" tree structure.
    Don't forget to define a local path used to identify that this project version is issued from a branch.
After making modifications in a branch, carry them over to the most recent project version (25, for example).
To perform this operation:
  1. Open the project in its most recent version.
  2. On the "SCM" tab, in the "Project" group, expand "Branches" and select "Retrieve modifications from a branch".
  3. A wizard helps you apply your modifications.
Minimum version required
  • Version 14
This page is also available for…
Click [Add] to post a comment

Last update: 05/26/2022

Send a report | Local help