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.
We recommend the use of the following tools:
• SVN commandline tools
• TortoiseSVN
• CODESYS SVN
In general you can work with the following workflow:
Use the folder "trunk" to write and commit all your code
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"
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 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.
You should avoid to work in the same repository with different clients. So you should not use an SVN client like Tortoise SVN and CODESYS SVN on the same repository. The reason is, that the risk of committing specific files with the wrong tool is too high.
To reduce this risk, you can use the tool cforge to checkout and update the repository on your PC, as cforge will not checkout internal files of CODESYS SVN.
This is the layout, how cforge would commit the data, but which you should avoid when you maintain the repository without cforge:
MyHeatingControl.project
pumps.library
sensors.library
MyHeatingControl/...
pumps/...
sensors/...
It is recommended to use a separated repository for CODESYS projects. Separating the code which is maintained with different SVN clients makes the handling of branches and tags easier.
CODESYS SVN is usually a comercial add on for professionals. But it can be used for free to access repositories from CODESYS Forge. You can get it from the CODESYS Store.
CODESYS is always backward compatible. So you can use an older library or project always with a newer version of CODESYS. So usually you should not encounter any compatibility problems between you and your users, as they can always use the most current version of CODESYS.
But converting the projects and libraries forth and back all the time is no good idea. So when you are working with a small team on a project, you should decide to use one specific project format within the team.
The contineous integration system on CODESYS Forge is obviously also based on a specific version. So check the documentation if you work with that.
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.
This is the version of the repository where everyone is working on. It can be compared to the "trunk" in SVN.
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.
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 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.
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.
Wiki: Continous Integration
Wiki: Contribution
Wiki: IndexMain