Version control (sort of)

  1. 5 years ago

    Marc

    10 Mar 2019 User since 2018
    Edited 5 years ago by Marc

    You may have good reasons for choosing the currently project file format, and it certainly has a number of advantages. One disadvantage I can think of is the inability to have some version control. For my daily work we use Github, for which you need (of course) open textual files.

    For my personal purposes I don't need full fledge version control, like commits and reverts. I just like to look back at changes I made; eg. I changed the color of control X from red to black. Or I changed some code.

    Maybe you could support this:

    1. At every project save (to the close project file), export the code and control settings also to open descriptive textual files. Just for readonly purposes, that I could commit to my version control system with some comments.
    2. Or: use an internal log in which you can lookup the changes. Eg. on March 8, you changed this code ... to this ...

    It's not a must have for me, but it would make some things easier. Sometimes you make some mistakes, and then you have to remember what you did.

  2. marco

    10 Mar 2019 Administrator User since 2016

    I agree @Marc and we already explored several possibilities.
    We use GitHub daily and so we know very well what you mean.

    One possibility would be to change file format from a binary sqlite database to a series of JSON files (one for each object). That would be a version control system friendly format and it will solve all the binary related issues.

    We are still exploring other solutions.

or Sign Up to reply!