I'm trying to use version control, and it looks as if the mbppi file is needed as it contains important settings, but it also appears to change in response to minor details such as which files happen to be open in the IDE.
Could the minor IDE details be split out into another file.
Remove IDE state from project file
-
filip.grujcic
- Posts: 822
- Joined: 14 May 2018 08:34
Re: Remove IDE state from project file
Hi,
I'm not sure about that, but I will definitely forward your suggestion to our developers for consideration.
Kind regards,
I'm not sure about that, but I will definitely forward your suggestion to our developers for consideration.
Kind regards,
Filip Grujcic
Re: Remove IDE state from project file
Here's a really simple example of something saved in MBPPI that probably shouldn't be...
Consider the library manager: if I select or deselect libraries this information is stored in the MBPPI file, as it should be (this is important to building the project)...
but...
If I expand parts of the library manager view this information is also saved in MBPPI!! This isn't needed to build the project, and it is quite likely to change for trivial reasons.
I'm not saying this information shouldn't be stored, just that it should be moved out of MBPPI into another file.
OK to try to elaborate on it a bit you have a project file, which contains important details about how to build the project
Important details might be what files are included, what libraries are used and in the case of Mikrobasic also the PIC configuration. If you were passing a copy of the project to someone they'd need all that in order to build it.
Then you also appear to have "local" information about the state of the IDE such as what files happen to be open, which isn't needed to build the project. If more than one person is working on it they probably do not want the IDE state synchronised as they may not even be working on the same files. Since the act of opening the project is often enough to change this information you'd want it excluded from revision control.
By splitting this out into two files you make it possible to put the build instructions in revision control, but the IDE state can still be excluded so the act of viewing a file doesn't create a "change".
It also has the benefit that if someone manages to break the IDE in some wierd way they can simply delete the file and reset it.
Consider the library manager: if I select or deselect libraries this information is stored in the MBPPI file, as it should be (this is important to building the project)...
but...
If I expand parts of the library manager view this information is also saved in MBPPI!! This isn't needed to build the project, and it is quite likely to change for trivial reasons.
I'm not saying this information shouldn't be stored, just that it should be moved out of MBPPI into another file.
OK to try to elaborate on it a bit you have a project file, which contains important details about how to build the project
Important details might be what files are included, what libraries are used and in the case of Mikrobasic also the PIC configuration. If you were passing a copy of the project to someone they'd need all that in order to build it.
Then you also appear to have "local" information about the state of the IDE such as what files happen to be open, which isn't needed to build the project. If more than one person is working on it they probably do not want the IDE state synchronised as they may not even be working on the same files. Since the act of opening the project is often enough to change this information you'd want it excluded from revision control.
By splitting this out into two files you make it possible to put the build instructions in revision control, but the IDE state can still be excluded so the act of viewing a file doesn't create a "change".
It also has the benefit that if someone manages to break the IDE in some wierd way they can simply delete the file and reset it.
