PLCnext Engineer and GIT
hi, it's me again.
I am using GIT for versioning, source control and sharing between team members.
The way PLCnext engineer has organized text files in a flat project is very "un-gitty":
When working in one file in PLCnext (e.g. a hmi page, a POU-file, or any entry in the project or component tree), several file system files are changed.
For instance: What I see as "one" POU-file inside PLCnext engineer consists of multiple files in the file system. There's one for the variables, one for each code sheet, description, settings, resources and so forth.
These files have somewhat messy looking names which you have to sift through when staging a commit.
Let's say that you did some work in 3-4 POU files, updated an HMI page and created a function.
Suddenly you have three dozen files you have to sort through to stage them correctly.
Proper staging in git entails that one commit deals with one specific feature or bug, and if you created one POU, you would think that it should be one commit and one file - not 8 files with strange-but-semi-recognizable names.
Below is a screenshot of the files created in the file system when creating one new function :
In addition to these come 10+ project files which are changed in various places.
I understand the sentiment for splitting the plcnext files into different file system files, but I also think it is possible to put most of these files into one file, e.g. start with the variable declaration, then all the code sheets, and all the other at the bottom. Maybe the html and rtf files can live as separate files so as to separate code from documentation.
Another problem is that creating new files (a function block for instance) also updates key project files, so that if any member of the team does this, he has to make sure that no other team member is doing anything that affects the project files as there will be merge conflict issues. It actually means that if any co-developer in the project does something that changes the project file, he has to let all the other members know and force them to pull his change into their code before its someone else's turn to do changes that affects the project files.
I also would like to see a list of files that git should or could ignore, such as the garbage bin, watch-list, logic analyzer and such which in many cases make no sense to share with other team members or keep track of in terms of version control.
Is "git-friendlyness" something that has been discussed when deciding how a flat project should look like?
I'd love to hear something about what pros and cons there are.
note: I have not tried the built-in version control, let me know if that has any built-in features that handles the above challenges.
(My previous employer used Bachmann Solution Center where each "plc file" was represented by one file system file, and creating new files did not update any other project files. The software simply used the .st or .dt files which was available in the project folder without indexing them inside other project files.
That was very git-friendly as it also made it possible to create a sub-repository inside the main git repository. In there we would store function, function blocks and datatype sheets which would synchronize between all other projects - just like a library - but without the fuzz of actually having to maintain a lib file.)
Comments
I completely agree with you! This is very inconvenient. Dear developers, do something about it
I totally agree.
Marcello
Dear fluxmodel,
first of all, I would like to thnak you for the good feedback.
Youre absolutely right, the actual physical storage of projects is not very GIT friendly, or better to say - not usable for multiple developers on one project.
We know that and even due to that, we would never say that this is our solution for co working on sigle projects. Actually I would say, we only have a solution for versioning of a project.
When we developed the "flat file system" it was not considered to be GIT friendly. The use case for that was totally different.
Due to the fact that we know all these disadvantages, we are actually in the phase to investigate what to change in the physical storage of projects by keeping in mind, that multi user functionality and GIT/SVN friendlyness is one of the major tasks.
I hope the result of this investigation will be a new storage format released in one of the versions next year.
Kind regards
Carsten
Thank you very much for your understanding @Carsten PLCnext Team .
I look forward to what the future brings :)
Hi again, @Carsten PLCnext Team
I was wondering if you can shed some light as to how you envision the future PLCnext Engineer would save files to be more "git friendly".
Anything you can share would be helpful as I am very curious about how we can collaborate and track revisions in the future.
We are also looking forward to this update.
I am looking into Version Management using a VCS at the https://engineer.plcnext.help/2024.0_LTS_en/_index.htm#
Before following these steps, I have the following message in the toolbar:
I am able to acces git from external apps (added to environment variables). I am unable to find anything in the docs about a license.
How can I make use of this?
Dear Mr. Smets,
the VCS function in PnE needs a license which could be generated via our E-Shop.
You can configure the license in the following way.
Have a nice day !
You do not "need" the built-in version control system to use GIT with a flat project. I dont.
There are a few advantages by using the built-in, but mostly because it describes what most of the files actually are, while in normal git you might not know.
Also there are a ton of features missing from the built-in VCS, but for some light users it might do the trick. I dont understand why Phoenix actually want to charge money for this functionality.
Dear all,
for those who wanne test the internal VCS/GIT client functionality, a trial license is installed with PLCnext Engineer.
To activate it, you only need to use the file explorer and search for the PLCnext Engineer installation path in the folder
"C:\Program Files\PHOENIX CONTACT\PLCnext Engineer 202x.x\Licenses"
Inside that folder you can find so called Trial licenses which offer the AddIn for a test perioud of 14 days.
Please be aware that trial licenses and even emergency licenses(7 days) are only activateable once on each computer.
Topic - New storage format
We are currently working on a new storage format for projects with the intention also to be able to work with multiple developers on one project.
Unfortunately this development takes a huge amount of effort, but we are pretty sure that we can give a first impression with PLCnext Engineer version 2025.0
If we have a solution, we will inform about that in the community and via different social channles, so stay tuned about news of PLCnext Engineer.
Kind regards
Carsten
Allright, thanks for the updates!
I'm unable to see something about that license, so that's why I was unaware.
I did experience that GIT problem in the past, good to see Phoenix is also investing in that functionality. I was wondering if something was changed about that and then I discovered the internal version management.
I'm looking forward to that functionality.
BR, Arne
Hello, any news about the New storage format as we are now at PLCnext Engineer version 2025.0? This would be very welcome update.
Br, Markus
I see no changes to the flat file system..
@Carsten PLCnext Team , any updates?