FHIR Chat · Excel Spreadsheet Merging · committers

Stream: committers

Topic: Excel Spreadsheet Merging


view this post on Zulip Grahame Grieve (Jan 17 2018 at 11:00):

Shortly, I'm going to commit a new feature to the build. The way it works is:
- when it runs into any spreadsheet that excel has saved, it will try to canonicalise the excel spreadsheet
- then it will try to save it
- if it can't, it will create a file [N}.please-close-this-in-excel-and-return-the-build-prior-to-committing
- it it can, it will save the updated one

If you see the "please-close..." this file, don't commit, and don't commit it. Close in excel and restart the build please.

When it comes to merges, you should no longer see any changes but ones that you made yourself manually. For a little while, please check the spreadsheet differences, and I will work on the canonical excel XML algorithm (some tricky stuff in there)

view this post on Zulip Grahame Grieve (Jan 17 2018 at 11:06):

this is preparation for migrating ot GitHub

view this post on Zulip Lloyd McKenzie (Jan 17 2018 at 16:28):

Would it not be better for the build to die and force closing the Excel files? Getting people to notice the existence of "please-close-this..." files when they're doing a commit could be hard. And as much as we set expectations for all committers to actively monitor this stream, the reality is not all will in a sufficiently timely manner

view this post on Zulip Lloyd McKenzie (Jan 17 2018 at 16:29):

Does this also mean that we must run a local build before committing? That's a major change. (And prevents things like "I can't make this work, can I commit and have you take a look at it?)

view this post on Zulip Grahame Grieve (Jan 19 2018 at 10:09):

no it would not be better to force you to close Excel. We all have the work flow:
- change something in excel
- do a differential build
- change something in excel....

view this post on Zulip Grahame Grieve (Jan 19 2018 at 10:10):

and yes, you must run a local build, at least till the point it starts the actual build, before you commit. Even if you are asking someone else to look. that's not new.

view this post on Zulip Grahame Grieve (Jan 19 2018 at 10:10):

and any committers that commit these files will be outed!

view this post on Zulip Lloyd McKenzie (Jan 19 2018 at 15:48):

Committing the "please close" files by accident seems unlikely. Committing spreadsheets that haven't been processed seems like it will be pretty common.

view this post on Zulip Lloyd McKenzie (Jan 19 2018 at 15:48):

And if the build runs with non-processed files, there's not going to be a huge incentive to remember to process them.

view this post on Zulip Grahame Grieve (Jan 20 2018 at 05:17):

it would certainly be better. But I won't force closing excel in order to run the build - well, not unless there's really no choice at all.

view this post on Zulip Grahame Grieve (Jan 20 2018 at 05:18):

There's one other choice I considered: banning the x-spreadsheet.xml files from version control, and generating them on the fly from the real master, and writing the real master from the spreadsheet files. This works around the excel locking problem, but adds a layer of complexity

view this post on Zulip Grahame Grieve (Jan 20 2018 at 05:19):

An alternative is that I can set it up so the the CI build refuses to build on non-processed files

view this post on Zulip Lloyd McKenzie (Jan 22 2018 at 15:53):

I like option #3. It makes the ramifications of messing up immediately clear (including who's at fault) without any digging. It's also not a roadblock to someone else as they can always run a full local build themselves and commit. And once we move to Git, a clean CI build would presumably be a pre-requisite to merging a change into the main build.


Last updated: Apr 12 2022 at 19:14 UTC