CODESYS stores the whole project as one binary .project file, so a plain Subversion client gives you rollback but no way to compare or combine two engineers' edits. Use the CODESYS SVN add-on for the daily multi-engineer workflow; it versions each application object in a central Subversion repository. Keep XML export for readable differences, and prove the choice with a two-engineer test on a disposable copy before you move the team.
You are about to move a project onto a controller programmed in CODESYS V3, several engineers will commit to it, and your team already runs Subversion for other work. CODESYS keeps that project in one file your existing client can store but cannot see inside, which is exactly how a colleague's edits get edited out of a build. Compare the three realistic paths below, then settle it with a two-engineer test on a disposable copy before you order any hardware.
The short answer
Use the CODESYS SVN add-on when 2 or more engineers commit to the same project. The add-on connects CODESYS to Apache Subversion and versions all application objects in a central repository, so the thing a commit captures drops from 1 opaque file to individual objects, and the compare runs inside the IDE where those objects live. Keep XML export for readable differences: a reviewer who never opens the IDE, an audit, a change note. Keep a plain Subversion client on the project file for nothing beyond rollback of whole builds.
Two things decide it: the count of engineers with commit rights, and whether anyone outside the IDE needs to read the differences. 1 engineer means the file and a client are enough. 2 or more engineers makes object-level compare mandatory, because the alternative is a whole-file conflict that lets 1 version survive whole and the other go by hand.
What actually reaches version control
CODESYS V3 stores a project as a single .project file, typically 1 to 50 MB for a machine project, in a proprietary binary format. An ordinary Subversion client handles that file without complaint: every commit adds 1 numbered revision, and you can check out any earlier revision of the whole project. That is where the good news ends. The client sees a binary blob, so 2 revisions show as binary files differ, with no object names, no line detail and no merge.
Run the two-engineer situation against that. Engineer A commits the file. Engineer B has local edits in the same file and updates. Subversion stops on a whole-file conflict it cannot display, and the team keeps 1 version whole or the other by hand. A commit that succeeds proves the path to the repository; it does not prove the edits inside are readable or combinable.
The CODESYS SVN add-on exists for this gap. Its documentation describes an integrated connection to Apache Subversion for all application objects, with the objects of the project versioned in a central repository. The unit of change becomes the individual object: the logic blocks, the visualisation screens, the device configuration. Whatever an engineer touched is what the revision records.
One file is also one point of failure. When a .project file will not open at all, the steps that sometimes bring it back are in recover a corrupt CODESYS project file after a crash. Object-level versioning shrinks that risk too, because any stored revision of any object can be retrieved on its own.
Side by side
| CODESYS SVN add-on | XML export with your existing client | Plain client on the .project file | |
|---|---|---|---|
| What gets versioned | Every application object, in a central Subversion repository | The XML files you export by hand | 1 binary file |
| What a difference shows | Object against object, inside CODESYS | Text, readable in any diff viewer | Binary files differ, nothing more |
| Combining 2 engineers' edits | Settled per object in the IDE | Text merge, then rebuild before anyone trusts it | Impossible; 1 version wins whole |
| Rollback | Any stored revision of any object | Re-import an older export | Any earlier revision of the whole file |
| Work per change | Update and commit inside the IDE | Export, commit, import on the other side | Commit the file |
| Fits | 2 or more engineers on 1 project | Reviews and audits that need readable text | 1 engineer, history and rollback only |
Where each path wins
The add-on wins the daily work. 2 or more engineers committing to 1 project need the compare and the conflict to happen at the scale of the object they edited, inside the tool where they can fix it immediately. Install the add-on, point it at the repository your team already runs, and commit from the IDE.
XML export wins the review. A quality engineer, a colleague on another team or an auditor can read exported XML in any text or diff viewer without installing CODESYS. That is a reporting job. It adds an export and an import to every change, which is overhead you do not want on every commit, so keep it out of the main loop.
The plain client on the .project file wins a single-engineer project. 1 engineer cannot collide with themselves; revision history of whole builds plus rollback is the entire requirement. It also keeps serving every non-CODESYS repository you already version, and installing the add-on takes nothing away there.
If your shop has settled on a different system entirely, that is its own subject: control CODESYS project files in Vault without ENI covers that setup.
Example: the two-engineer test on a disposable copy
Run this on a copy of the evaluation project before the controller order, never on production code. The whole test fits in about 60 minutes: 30 minutes for case 1 and case 2 under the plain client, 30 minutes under the add-on.
Inputs, and where each comes from: 1 evaluation project, stored as 1 binary .project file of about 10 MB, the documented CODESYS storage format; 2 engineers, A and B, the smallest team where 1 can overwrite the other; 2 edit cases, case 1 with A and B editing 2 different objects and case 2 with both editing the same 1 object; 1 disposable copy of the project and 1 empty test repository, which starts at revision 0 so nothing predates the test.
The rule, in words: run each case under both paths, add-on and plain client. After both engineers update and commit, a case passes only when both intended edits are in the shared project, or the tool names the colliding object so an engineer can settle it deliberately. Score the cases out of 2.
The arithmetic, plain client on the file: A commits the file; B, holding local edits in the same 1 file, updates and hits a whole-file conflict that cannot be displayed. The team keeps B's version or A's, never both: edits combined in case 1, 0 of 2; in case 2, 0 of 2. Score 0 of 2 cases, and in neither case did anyone see which object changed.
The arithmetic, CODESYS SVN add-on: case 1, A's object and B's object are versioned separately, so both edits land untouched: 2 of 2 edits, pass. Case 2, both edits strike 1 object, so the tool has exactly 1 colliding object to name and the compare shows both sides for a human decision: pass when it does. Score 2 of 2.
Result: plain client 0 of 2 cases; add-on 2 of 2 cases with 1 conflict to settle.
The decision: standardise on the add-on only at 2 of 2. A score under 2 of 2 means the workflow lost or hid an edit on your own project, so do not move the team onto it until that is fixed.
Keeping XML export safe when you need readable text
XML export earns its place as a report under 3 rules.
Pick 1 authoritative artifact. If the .project file is the master, the export is a picture of it: commit the export beside each change it describes, and never let 1 engineer edit the XML while another edits the project. 2 masters means 1 of them is stale, and the stale one is the one somebody trusts.
Round-trip it once before you rely on it: export the project, import the export into a scratch project, and build. If the imported project will not build, the export path is incomplete for your objects, and the readable differences it produces describe an incomplete project.
Treat a merged export as a candidate until CODESYS has it open and built. A text merge can produce well-formed XML that is still a broken project: the syntax checks out and the references do not. Rebuild after every merge, and read the diff for the intended change only, because exporters also move formatting.
The decision
Recommendation: standardise on the CODESYS SVN add-on for any project with 2 or more engineers committing to it, and set it up before the replacement controller is ordered, not after. Keep XML export as the readable-difference report for reviews and audits, allowed onto the list once 1 export-import-build round trip on your own project succeeds. Keep the plain client on the .project file only where 1 engineer owns the project and rollback of whole builds is the entire requirement. Gate the move on the example above: 2 of 2 cases on a disposable copy, or the team stays where it is.
The same evaluate-first order pays on the hardware around the project too: choosing an EtherCAT I/O replacement your CODESYS project accepts applies it to the devices you attach.
Questions
Is there a Git path for CODESYS projects?
Yes. CODESYS Git is a separate add-on, and its store page gives the reason it exists: the project storage CODESYS normally uses is not suitable for a version control system, so CODESYS Git ships its own storage. The acceptance logic is the same as for Subversion: objects versioned individually, compare inside the IDE, and the two-engineer test passed on your own project before the team moves.
Does the add-on replace the Subversion server we already run?
No. The add-on is a client that connects CODESYS to Apache Subversion, and the objects land in a central repository on your server. The server, its backups and its access rules stay as they are. What changes is where engineers commit from: inside the IDE, object by object, not through a file browser.
Do we still need project backups if every object is versioned?
Yes. Version history answers what changed; a backup answers what happens when the file will not open. Keep one buildable baseline of the .project file outside the repository, refresh it at every milestone, and keep the repository itself in your normal server backup schedule. If a project file is already damaged, work from the last known buildable copy, not from the newest revision.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.