Musescore Chronology

• Aug 26, 2022 - 19:48

Hi,
I've been wondering if MuseScore has some kind of chronology system that shows the changes that have been made. If not, I think it would be a useful addition to MuseScore!

Keep up the good work,
MRJ


Comments

In reply to by Marc Sabatella

(Updated with Jojo's proposal below)

It is indeed a problem to be able to compare changes in different git commits. using regular git commands you will only see updates in the xml files which will often be difficult to understand. I wrote a feature proposal in this very forum some years ago to address this:
https://musescore.org/en/node/313538

Which was then converted into a feature request (Suggestion) in the issue tracker:
#314036: invoke the score-comparison view from command line

In short, MuseScore already supports showing the difference between two versions of a score, but it is not possible to integrate with git. But that should be possible by adding some more command line options.

In reply to by MRJ_MRJ

Workaround

• Create new score, e.g. MyScore
• Save As MyScore.mscz
• Save As MyScore-000.mscz
• Close score

Update #1 :

1 • Open MyScore-000.mscz
2 • Save As MyScore-001.mscz
3 • Make changes, saving periodically
4 • Repeat 3 as required then finally ...
5 • Save As MyScore.mscz
6 • Close score

Update #2 :

1 • Open MyScore-001.mscz
2 • Save As MyScore-002.mscz
3 • Make changes, saving periodically
4 • Repeat 3 as required then finally ...
5 • Save As MyScore.mscz
6 • Close score

:
:

Update #123 :

1 • Open MyScore-122.mscz
2 • Save As MyScore-123.mscz
3 • Make changes, saving periodically
4 • Repeat 3 as required then finally ...
5 • Save As MyScore.mscz
6 • Close score

This keeps a history and maintains MyScore.mscz as the current version.

(But Git is a better solution)

In reply to by msfp

I use this sort of scheme when developing Microsoft Power BI reports, until the first release which becomes 1.0.0 and then I follow the same style as MuseScore release numbers.

The continuous same file name for the latest version means that the cloud published version does not keep changing its URL.

In reply to by yonah_ag

It's "sort of" true, but only in a way that completely misses the point. The MSCZ contains an entirely unnecessary second copy of an image, which is still right there on your computer where it was before you added it to the score - assuming you added the image from a file. It is true that if add the image directly from the clipboard in a way where it was never saved as a file, it doesn't survive the save, so if you intend to use MSCX, definitely don't do that - save the file somewhere first.

But once you've enusred the image actually exists as a file, you're not losing anything at all by using MSCX - you're just avoiding unnecessary duplication. And while a single MSCZ file takes less space than a single MSCZ file, this less is true if there are images involved, and it won't be true at all by the time you store a dozen of so revisions in git. That's because git is extremely efficient at maintaining multiple revisions of text files, by storing only the "diffs". So 100 revisions of a score in git will virtually always take far less room than 100 copies of an MSCZ file, especially if images are involved, because now you've got 100 extra copies of those images, too.

In reply to by Marc Sabatella

I guess for history versions the loss of images in the MSCX are not really an issue but it's something to be aware of in other circumstances. Storing diffs is certainly an excellent way to do things - I might even switch to Git for my history, (especially as my banner images are all saved and backed up.)

Do you still have an unanswered question? Please log in first to post your question.