Version control software

[Dag-Are.Trydal@nov.com]

I'm using GIT to backup my project, and share progress with others.

To avoid "noise" when doing commits, we have excluded some folders (mainly these):
* db/
* log


But there are two things I really miss to have revision control over.

1. The database. Specifically the datapoints and datapoint-types, not so much the actual-values of the datapoints. Where is the database stored in the project folder? And do you have any experience on using revision control software on the OA database?

2. The Panel Topology. Where is it stored?

[kilianvp]

The DB is per default under our project folder in "db\\wincc_oa\\"

don't store the Database in a typical Version control software because it can get very huge and is in a binary format.

The Panel Topology is a interal Datatype "_PanelTopology".

If you want save changes of your DB in your Version control software export the changes with ASCII Manager as DPL file

[flindecke]

We are using GIT as well.

To handle the database part we are exporting all relevant types using the WinCC OA ASCII Manager to a file which is put under version control.
On startup of the project we can use a control manager (a script which looks at specific export files and calll WinCC OA ASCII Manager to import the files into the database) and start it once.

So a developer just checks out the branch and restarts the project (or just call the control manager which imports the ASCII files).

Same for the panel topology. But note, that all datapoints with a "_" prefix are "private WINCC OA" ones and can be changed in future versions.

[tmalone]

I helped write the SVN parts of the GEDI integration. If GIT has a command line interface with interactive dialog boxes, it would not be hard to adapt the svn control to use GIT. Has anyone looked into this?

[RudiKreiner]

We also had a look at using GIT for version control of our projects, but decided to stayewith SVN.
One of the main reasons for this ist that GIT only stores one version of non-ascii files.
Since we use excel files for administrating our language support and also for some of our data point declarations, we would have no longer been able to look at old versions.
We also have some non binary files for our PLC configuration, which would also be affected.
Same would be for the pixmaps, which may or may not be of interest.

Maybe these issues are not relevant for everyone, but I want to mention it here anyway to help with your decision making.

[mkoller]

"One of the main reasons for this ist that GIT only stores one version of non-ascii files."

This is simply wrong.
(Just to be sure, I double-checked with a PNG file)

How did you come to this result ? Any pointers ?

[flindecke]

As long as i know GiT uses an algorithm to decide if it stores delta or the whole binary file.
The problem with GIT binary files is, that whenever you clone a repository, every old version - even the unused of current branch - are inside the history of the repository. Therefore some people prefer other options (e.g. git annex, https://git-annex.branchable.com/) to store very big files.

Nevertheless GIT has no problems with big files (e.g. we are using them for photoshop files and these files can be big - 500 MB). If every commit stores the whole new version - and not the diff - repository will be bloated. But this is not the case.

If you have problems with binary files identified as binary files by GIT have a look at https://git-scm.com/book/en/v2/Customiz ... nary-Files

BTW: http://blogs.atlassian.com/2014/05/hand ... ories-git/ discusses several options to handle big (binary) files and http://blog.deveo.com/storing-large-bin ... ositories/ discusses some tools how handle big files.

BTW 2: Subversion has the same problem on the server, but hides it, due to the fact, that on the client side you will only have the current branch view (and not all branches like in GIT)

[RudiKreiner]

OK, i checked back with my sources and was wrong about the versioning of non-ascii files. Sorry for the confusion.

The problem we foresaw with the non-ascii files is actually that GIT has no locking mechanism so that parallel changes can be made, and there is no merging mechanisms to consolidate them.
This is probably not relevant for icons and pictures, but finding out who changed what in excel files, for example, and merging the changes to get the right final version can be quite tedious.

[flindecke]

I see the problem. Merging a binary file is @%"&!

In a distributed version control system there is no possibility in general to use locks. It depends on your organisation, how to handle it. E.g. if you have a central repo server where all developers has to push changes it might be possible to use hooks to prevent a push of an "already" looked file. But additional tooling is needed in such a case.
So in cases where several binary document owners are there, and there exists no communication between these people, there will always be the problem of locking.

But good to discuss this "problem" here for later decision taking of others.

[fmulder]

We do not use the SVN integration in the Gedi simply because there are files that do not show up in the Project View. Example: \\bin folder, \\source folder, \\data folder.
We use TortoiseSVN.

What we do use (quite a bit actually) is the fact that SVN can replace a keyword ($Revision$) in our source file. Example:

* Our script libraries have a string variable string strMyLib = "$Revisuion:2314$";
* These numbers are added to a global dyn_string automatically
* The About box will automatically show all the version numbers from our (mostly encrypted) libraries
* I'm always sure that I see all numbers in my About box. The whole thing is automatic and there is no way that I can forget a library

We do something similar in our panels.

I really like this feature because it helps us to diagnoses when someone finds a bug in a runtime application with encrypted libraries.