SCM Repositories

There is a newer version of this page. You can find it here.

For your project, you can choose between two different source code management systems. As CODESYS provides native support for SVN, we would always recommend that if you want to manage CODESYS projects.
In every other cases, git has the huge advantage, that you can work locally, make even local commits, and push everything to the master repository only after you are satisfied with the result.
Especially in distributed, open source projects, where all participants have their own goals, this is a huge advantage.

Subversion (SVN)

We recommend the use of the following tools:

• SVN commandline tools
• TortoiseSVN
• CODESYS SVN

In general you can work with the following workflow:

Trunk

Use the folder "trunk" to write and commit all your code

Tags

After you are satisfied with the software and you want to prepare a release, you can tag your trunk to a specific version.
To do so, just use "svn copy" to copy "trunk" to "branchea/v1.0"

Branches

In Distributet Projects it is a good idea if not everyone is committing to the same trunk when they are developing larger features. It is recommended to create a "ticket" to describe the development and create a branch to develop this feature.
After finish and review by other project members, one can then "merge" this change into the trunk.

CODESYS

CODESYS projects are usually saved in a propritary binary format. CODESYS SVN is an add on for CODESYS, which breaks this format out into several objects, which are then maintained in SVN. CODESYS itself is acting as the SVN client and the merge tool in this scenario.

A CODESYS project, which is imported into SVN or checked out from SVN has a connection to this repository, very similar to a folder which you checked out with one of the other SVN clients.

For convenience, we recommend to check this binary project or library, containing this connection to SVN, additionally in. This way, you can maintain the CODESYS in its binary form, as well as the SVN sources in one repository.

Here is a possible repository layout:

MyHeatingControl.project
pumps.library
sensors.libtary
MyHeatingControl/...
pumps/...
sensors/...

It is recommended to use a separated repository for CODESYS projects. As you use with CODESYS SVN another SVN client for it as you use for your other code, it makes the handling of branches and tags easier.

CODESYS SVN is usually a comercial add on for professionals. But there is community edition which can be freely used with CODESYS Forge.

Git

Git works in many respects very similar to SVN. In the following we will point out the conceptional differences when working in a Team.

We recommend the use of the following tools:

• Git command line
• Tortoise Git

Note, CODESYS doesn't support Git at the moment. See the chapter below for more details.

Master

This is the version of the repository where everyone is working on. It can be compared to the "trunk" in SVN.

Fork

Every larger change should be done in a fork, which can be compared to SVN "branches". A fork can later be merged to the master.

Tags

Contrary to SVN a Tag in Git doesn't create a nee Revision. It just names this Revision. Actually it is more similar to CVS labels.
Tags can be used to mark releases Versions. Release Tags shall only be used on the Master.

CODESYS Libraries

CODESYS supports to store projects or libraries in SVN. As you need CODESYS to resolve conflicts it is always a good idea to use an own Repository for CODESYS libraries or projects.

Merge Requests (aka Pull Requests)

In Git you can place so called "Merge Requests", which are very similar to "Pull Requests" on GitHub.

You are free to use those on CODESYS Forge for your project. But, as we propose a multi-repository project layout in combination with SVN for CODESYS projects, we don't suggest it.

To track branches, which need to be integrated, we recommend the use of Tickets.