-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
merge script #8
Comments
Merge script code is on https://github.com/Mathadon/BuildingsPy/tree/issue278_mergeMpc |
@Mathadon I do not have any experience with the merging of the IBPSA Library into other libraries, so the code related to that, specifically in BuildingsPy, I am still learning. But from what I can tell, your suggested approach (implemented in #3) seems OK to me. I agree with not having automated git commits. This is definitely an expert-only process to embark on. But I was able to replicate the functionality using the code in your PR. One note/emphasis is in 1) your suggested use of the Also, when the process is complete, should |
First comment; that is correct. I have added
Second comment;
Should I make a PR for buildingspy already or do we test it further first? |
Sounds good. I think test a bit further before making PR for buildingspy:
|
Let's develop it a bit further then before doing the time investment in documenting. |
I have completed (the first version of) the merge script. The merge script relies on the git patch functionality, which can generate merge conflicts to sort out conflicting edits. Furthermore, I prefer not to make automated git commits. Therefore, the merge process is now split up in two steps, which consists of multiple commits and two python calls to https://github.com/ibpsa/modelica-ibpsa-mpc/blob/issue1_sources_modifications/IbpsaMpc/Resources/Scripts/merge.py.
The following instructions are generated upon calling the merge script for the first time:
and these the second time:
What happens in the back-end: the file
.copiedFiles
contains the sha of code before the previous patch was applied. When starting the script, a patch file is generated compared to this sha and stored to file (only for the files that are listed in the script), which effectively summarizes all changes compared to last merge. After that the file selection is copied from the IBPSA library using the normal merge scripts, which overwrites custom changes that may exist in these files. The file.copiedFiles
is updated, but does not contain the new sha yet. This version of the code has to be committed for the patch process to work and the sha of that commit is also saved in.copiedFiles
in phase 2 of the merge script. In phase 2, the sha is amended to .copiedFiles and further instructions are printed to apply the patch, which may or may not result in merge conflicts, which must then be resolved, then committed by the developer.This works for the
checkBoundary()
removal (without merge conflict) but I'm sure that corner cases will pop up. @dhblum any feedback on this?The text was updated successfully, but these errors were encountered: