Key Issue Type Summary Resolution Release Note
SVN-1042 Bug

Revert to revision on included externals does not recognize a move out of subtree

SVN-1014 Improvement

Downgrade minimum target to CODESYS V3.5.17.10

SVN-993 Bug

SVN: Project log filter shows empty log if no revsion range is selected

SVN-992 Improvement

Update AddOn SDK to V3.5.18.0

Fixed [[GENERAL]]
Update SDK to SP18.
Package can only be installed to CODESYS Version >=SP18
SVN-986 Epic

Profile compatibility

Fixed [[GENERAL]]
Every time a SVN operation is about to change either the project's storage format, or the SVN repository's storage format, a warning or prompt informs the user about it. This is called a profile compatibility check and intents to prevent a project with mixed storage format, which might imply incompatible behaviour, such as editors not being able to display object data (reading) or data loss (writing). The following means aim to always keep a project consistent with the same storage format for every object:

- When fetching data from the SVN repository into the CODESYS project (e.g. 'svn update'), the user is notified about profile differences and prompted whether to continue the operation or not.

- When commiting data from the CODESYS project into the SVN repository, the commit dialogs display a warning, that the commit will change the SVN repository's storage format. The user has the option to abort the commit, or to use the "Save as..." file command to change the project's storage format. In any case, a change to the storage profile file 'meta.profile' is a mandatory part of a commit.

These new profile compatibility checks apply as follows:

- SVN commands to fetch data from the SVN repository into the CODESYS project (e.g. 'svn update') have the new user prompt enabled by default. A new option in the "SVN settings" allows to disable them, effectively restoring the legacy behaviour. This does not apply to the commit warning, as this did not introduce a new user prompt and therefore is considered a non-breaking change.

- All script driver methods remain unchanged, none of the new checks is run

- All test driver actions remain unchanged, none of the new checks is run

- Commit actions from within the 'Pending changes view' now implement the same checks as the 'Commit changes' dialog, if the project's BASE revision is HEAD, or if an 'svn update' is advisable. If the user decides not to update to HEAD, an additional confirmation is required, as this might be an operation breaking storage format consistency of the SVN repository.

- If a profile compatibility check finds a differing storage profile for a non-project wide SVN operation (e.g. 'svn update' of just one POU), the operation is cancelled to prevent a storage format inconsistency in the project. The user is advised to run the corresponding project-wide operation to resolve the situation.

- The following SVN operations are not affected by this check:
-- Mark as resolved: uses the current state of the project / working copy
-- Resolve using ours/theirs; user decision
-- Modification of SVN properties: Uses the current state of the project / working copy
-- Include externals: Usage of SVN externals introduces arbitrary storage formats from different projects. Therefore no support for profile compatibility can be given.
-- Handling of object name collisions: uses the current state of the project / working copy

The new profile compatibility checks come with some limitations:
- They only work reliably for storage profiles, that exclusively use the 'fixed' version constraints. For any other version constraint it is impossible to compare these profiles.

- The new user prompt might be followed by another, legacy dialog titled "Storage format upgrade". This dialog needs to be canceled in order to apply the SVN repository's storage format to the project instead of CODESYS' startup profile format. This issue will be addressed by CDS-82070 and CDS-82071.

- When changing the project's storage format using the "Save as..." file command, it is mandatory to add all Add-on packages used in the project to the storage profile. Otherwise the next commit is likely to break the SVN repository's storage format compatibility.

- When changing the project's storage format using the "Save as..." file command, the ability to add Add-on packages to the project's storage profile is only available for those profiles, that are stores as 'Informational Profile' in the correpsonding folder of the installation.

- When changing the project's storage format using the "Save as..." file command and adding Add-on packages to the profile, the resulting profile's name might be empty. This will be addressed by CDS-82228.

- CODESYS SVN's profile compatibility check are yet unable to display profile differences restricted to different Add-ons. A 'CODESYS V3.5 SP18' with 'CODESYS UML' AddOn will just be displayed as different to a 'CODESYS V3.5 SP18' without 'CODESYS UML', but with both profiles being named 'CODESYS V3.5 SP18'. This issue will be addressed by SVN-1025.

- Projects saved as storage profile older than 'CODESYS V3.5' will not be checked, because the do not contain a storage profile indicating the storage format.

- When canceling the profile compatibility check's prompt for the SVN command "Revert to revision", the project will not remain untouched, but will still be reverted to BASE.

- CODESYS SVN does not yet interface with CODESYS' Installer Integration, meaning, that it does not provide the possibility to install or start another installation, if the project created by a SVN operation cannot be opened without restrictions by the current installation. This issue will be addressed by SVN-1006.

The minimum target version has been raised to CODESYS V3.5.17.0.
SVN-973 Bug

Meta.profile downgrade inconsistent with "svn update" and similar operations

Fixed [[GENERAL]]
Whenever SVN is about to write object data to the project, that has been written with an other storage format than the current project's one, the project now needs to upgrade/downgrade to that storage format (implicit "Save project as...."). The user is prompted for contiuation or abort.
This mechanism can be outped-out in the global SVN settings "Project compatibility", restoring the legacy behaviour. ScriptDriverSvn always implements the legacy behaviour, regardless of that SVN setting.
SVN-971 Bug

Tree Conflict caused by concurrent deletion cannot be resolved

Fixed [[GENERAL]]
For tree conflicts caused by a concurrent deletion of an object in the working copy and the repository only the command "Mark as resolved" is available.
SVN-970 Improvement

Disconnect: Release locks before disconnecting

SVN-969 Bug

SVN: Copy operation leads to loss of history

Cannot Reproduce [[GENERAL]]
If only the last commit can be seen in the log of an object, the option "Stop on copy/rename" has to be disabled. Additionally it could be necessary to refresh the log by using the buttons "All" / "Next 100".
SVN-965 Bug

SVN: Not able to recognize if an object has been locked by another user

Won't Fix [[GENERAL]]
Won't fix: Functionality works "as designed".
For objects that are locked, by another user, a yellow lock icon is shown (not to be confuesd with the small blue lock icon for locks of the current user).
This icon is updated at three times:
* periodically after the "Check interval" from SVN settings (default 15 minutes)
* imminent object modifications
* svn update
SVN-958 Bug

Delete and Add object recognized instead of change

Won't Fix [[GENERAL]]
Won't Fix: The current behaviour has never been changed and therefore is "as designed", not a bug. Changing the behaviour in the described way would be an improvement. However the necessity of it has become obsolete, because the requesting stakeholder has changed their plugin (Application Composer) to generate stable Object GUID's via the approach of name-based GUIDs. This is in general considered the favorable way for a source control friendly plugin (see also GIT).
SVN-951 Bug

Corruption of project by regular copy-paste-rename workflow

Fixed [[GENERAL]]
If a object or subtree in is duplicated (e.g. by copy & paste), the duplicated object(s) are implicite under svn control. This behavior matches the behavior of "svn copy" and is as designed.
Duplicated objects that are located within the same namespace as their corresponding original objects, get a unique name by adding a numeric postfix. This is the standard de-duplication mechanism of CODESYS for names of inserted objects. Because of this the duplication of objects consist of two steps: duplicating objects and de-duplicating names.
For all affected objects, this causes an implicit
1) modification because of their changed name and/or changed path within the working copy of svn.
2) deletion of the duplicated object before renaming.
This also affects all child objects of duplicated objects.
This matches the behavior of tools like TortoiseSVN. CODESYS SVN only consolidates the addition and modification of the duplicated objects.
SVN-947 Bug

Update SharpSvn for security issues

Fixed [[GENERAL]]
Updated SharpSvn to version 1.14001.156 to address security issues in OpenSSL
SVN-945 Bug

Meta.profile change not a mandatory part of commit

Fixed [[GENERAL]]
If meta.profile is changed it needs to be commited or the project saved as designated CODESYS Version
SVN-914 Bug

Security: Use BinaryProfileFormatter instead of BinaryFormatter

SVN is only installable on CODESYS >=SP17.

For more details see Advisory 2021-13, which is available on the CODESYS website:
SVN-901 Bug

SVN: Merge conflict resolver shows object state denoted "Special"

Fixed [[GENERAL]]
When merging objects from CODESYS SVN's "Offline Mode", the merge/compare viewer's side, that shows the data incoming from the repository is not denoted "Special" anymore, but "Incoming".
SVN-899 Bug

KeyNotFoundException when executing svn commands with --noUI –textPrompts

Duplicate [[GENERAL]]
Duplicates SVN-910
SVN-892 Improvement

SVN AddOn packages should be digitally signed with a certificate by CODESYS

Duplicate [[GENERAL]]
Duplicate SVN-956
SVN-870 Bug

SVN: Show Properties: Unhandled exception

SVN-788 Bug

SVN: Comparison in history wrong when filter is active

Duplicate [[GENERAL]]
Duplicates SVN-612
SVN-708 Bug

Log History: A date filter before first revision cannot be deleted

SVN-612 Bug

Log: "Show changes" fails, if comparison base is masked by filter

SVN-509 Bug

SVN: If a filter in the 'project log" dialog is used no changes of the last entry can be displayed

Duplicate [[GENERAL]]
Duplicates SVN-612
SVN-135 Improvement

SVN: Speedup some operations by using lazy loading in the AddMultipleObjects call.

Won't Fix [[GENERAL]]
Will not be done anymore for SVN