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 :
image.pngIn 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.)
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.
