Why is unpacking DataDistrib.zip needed?

[SoftAllan]

The needed files are in the DataDistrib.zip file but why are they not already unpacked in the Data folder of the project when checked out? Another issue it that there are already some files in the Data folder and this causes the unpacking to as the user if they want to override the files. I think it is neede to override but the "Read me" file does not indicate that.

[SoftAllan]

It seems that the tag files are the same (column names for the DataFlex files):
codemast.tag
codetype.tag
folderseldtl.tag
folderselhea.tag
functions.tag
statlog.tag
sysfile.tag

However the ScintillaEdit.ini file is different.

[SoftAllan]

Okay I just wanted to be sure that it could be ignored. I suggest that the ScintillaEdit.ini file find its way to the .gitignore also.

What I wanted to point out is that the tag files and the scintillaedit.ini file should not be present in the .git workspace when checked out. When you checkout the master branch with an empty data folder it would not give conflicts when unzipping the DataDistrib.zip file into the empty data folder.

[NilsSve]

The ScintillaEdit.ini file case is complicated. When a user makes changes with the ScintillaParameters.dg, those changes are saved to that .ini file and therefore it would make sense to have it in .gitignore.

However, there are other cases when the development team do wants to propagate out changes made to that .ini file to all current users of the tool. For instance, when the new default color theme used throughout of the workspace it also involved settings in ScintillaEdit.ini. It also contains a list of e.g. all DataFlex keywords. Those keywords and other settings are read by the cRefactorEngine when the TestBench and DFRefactor program is started and effects how the program operates. So it is complicated...

[NilsSve]

I'm sure you are right about the .tag files though. But I'm not sure how it should be corrected, now that the "damage is done"?

[SoftAllan]

I think it would be okay to delete the files in the Data folder as they are present in the zip-file. Or make a comment in the read me that you should override existing files?

[NilsSve]

Yeah, but I'm afraid that if I try to delete the .tag files now, GitHub Desktop will remove my local .tag files(!) Things like that has happened before with this project. Again, probably because of my lack of GitHub knowledge...

[NilsSve]

It is probably because of my lack of knowledge of how Git works. As the .dat files changes all the time and are "personal" to each developer/user, GitHub Desktop "barked about" that the .Dat files needed to be committed & pushed, something that should not be done. Hence the work-around zipping together an empty set of the .dat files into DataDistrib.zip.

How should this be handled in a more efficient way?

[SoftAllan]

Hmm.. you are right. Data files are binary files and should therefore not be part of the .git repository. Also the Index files are propably invalid when checked out as my collating file is Danish. I just reindexed the files before trying out the application just to be safe. But why should a zip file is different than some dat files as that is also a binary file?

Git has support for binary files with LFS. I have not tried that with GitHub though.

Maybe it should be an XML or JSON file that is read into the grid? As I understand the project you cannot dynamically add or remove refactory functions to the list. But I do like that the previous selection is present when opening a previous workspace. Really handy when having hundres of folders. That is the nice part of having the embedded database.

Another solution could be to have the system create a database when opening? Then read the default values from the JSON file to fill it?

[NilsSve]

A JSON file is used by the project. But not for what you describe. Instead, it is used to communicate changes made to the database, the cBasicRefactorFuncLib.pkg, cRefactorFuncLib and/or oUnit_Tests.pkg files with other users. The usage of this JSON Export/Import functionality can be found on the "JSON Export/Import" view of the TestBench program.

The idea is to make it easy if you e.g. add a function, to send those made changes to another user of the tool.
So you are right that one cannot dynamically add new functions to the framework, but it is quite straight forward to add new functionality and to share those changes with other developers by sending them an updated JSON file to import.