programRevision is not shown in Score Properties dialog for score from 2.0 and later
In 1.x the Revision was a plain int, like 5702 for MuseScore 1.3, and gets displayed as that when opening a 1.x file in 2.0, 2.1 or 3.0
In 2.0 though (actually since the move to git and GitHub) it is a SHA, containing digits and letters, a hex value, but still gets read in as an int, and, probably because not preceeded with a 0x, as a decimal int, this fails, because of the letters in the string, so gets interpreted and shown as 0. Also that revision field is limited to a max. of 99999, 5 decimal digits, while the SHAs (typically?) have 7 hex digits (at least)
Comments
see https://github.com/musescore/MuseScore/pull/2921
And https://github.com/musescore/MuseScore/pull/2936
programRevision, API-Level and MuseScore verson get updated to the current running one, once autosave kicks in.
This could get prevented by not autosaving 'imported' 1.x or 2.x score as long as they have not been modified. Added a corresponding commit to my PR for master (adding something equivalent to the 2.1 PR is yet to be done)
See also #152211: API-Level in Score Properties dialog shows the one from the version running, rather than the one from the score
Fixed in branch 2.1, commit 67dd683c9d
fix #152206: Revision is not shown in Score Properties
for scores from 2.0 (or later?), actually for scores created after the
move from sourceforge to GitHub
Fixed in branch master, commit 2bbf303530
fix #152206: Revision is not shown in Score Properties
for scores from 2.0 or later, actually for scores created after the move
from sourceforge to GitHub
Hmm, there's still something wrong, in master and master "My First Score" gets shown as github-musescore-musescore-35431 while it actually is 3543170
And it gets truncated to 5 digits (and a bit) for other scores. Hmm actually maybe the same problem?
Does this not work? Any better way to reserve space for (at least) 7 (hex) digits?
Increasing that 0xfffffff to INT_MAX improves this, but doesn't fix it, it still truncates after 6 digits and a bit (the last digit is only partly visible).
Still not sure why it didn't work before, I'm pretty sure I had it tested and verified. Anyway, this change now should make it work properly, see https://github.com/musescore/MuseScore/pull/3053
Reading 1.x files doesn't work currently in master, it crashes when trying to read those as 2.x files.
Fixed in branch master, commit 4f79b44fea
fix #152206: programRevision is not shown in Score Properties dialog for score from 2.0 and later
Fixed in branch master, commit 72ab8cb4ee
Merge pull request #3053 from Jojo-Schmitz/metaedit
fix #152206: programRevision is not shown in Score Properties dialog for score from 2.0 and later
Fixed in branch 2.1, commit 09308b0aee
fix #152206: programRevision is not shown in Score Properties dialog for score from 2.0 and later
Automatically closed -- issue fixed for 2 weeks with no activity.
Testing with 2.1 RC—revision is shown at first, but after saving, it reverts to 0. Is this intended behavior?
No, it should show the current revision then. And does on reload.
Correction: 2.1 shows the revision on reload, master does not. Both show revison as 0 on save.
No idea why.
Hmm, actually for master 5a42b3833 the Git SHA is not 7, but 9 digits now? See the post-checkout hook which calls `git parse-rev --short HEAD >/mscore/Revision.h` changed behavoir, it is documented to give a length of 7 if not told otherwise via `--short=n`. Change the hook to using `--short=7` fixes the display on reload.
Seems only to be an issue on self-built versions, not for the nightly builds. Probably down to a difference in git versions being used?
See https://github.com/musescore/MuseScore/pull/3145
Seems I found the culprit, see https://github.com/musescore/MuseScore/pull/3146
Fixed in branch master, commit 3b91efa95e
fix #152206 follow up: show correct revision after save too
Fixed in branch master, commit 38ed8ddb0d
Merge pull request #3146 from Jojo-Schmitz/revision
fix #152206 follow up: show correct revision in score properties after (auto-)save too
Fixed in branch 2.1, commit 958562d850
fix #152206 follow up: show correct revision after save too
Automatically closed -- issue fixed for 2 weeks with no activity.