Version Scores with Git

Hello everyone,

This post has two purposes, both related to the fact that I've been experiencing some difficulty with large scores in that MuseScore has a tendency to crash unexpectedly. This is usually not a problem because I can restore the session, but every once in a while it crashes during a save and my file gets completely corrupted! The size of the file is reduced to 0, and I have to start from scratch**. I very quickly learned to manually copy a backup file, but this was cumbersome, and I started making a new backup file each time, leading to bloat on my file system.

So, being a programmer, I naturally thought, "This needs Git." And so I started using Git.

The purpose of this post, then, is two-fold:

1. To document my solution to this problem using Git so that if anyone else is having these issues and would benefit from it, then hopefully this will help them out. This may or may not be a problem unique to my system, but I figure there's at least some probability that someone out there is having similar problems.
2. To make a feature request for native integration of version control into the MuseScore application itself.

For now I'm just versioning my scores locally on my computer. The nice thing about git is that it does not require a remote server. You could use github or bitbucket if you wish, but I have no need for that at the moment.

I'm running Windows 7 64 bit
I have downloaded and installed Tortoise Git (http://code.google.com/p/tortoisegit/)
I'm working with MuseScore 1.3, though this solution is version agnostic as far as I can tell.

I'm assuming you have some basic understanding of what version control is and how it works. If not, start here:
Getting Started: About Version Control

Essentially, for our purposes, we are using it to provide backups of our scores as protection against corruption caused by crashes during save. It could also be used to allow a team to collaborate on a project using MuseScore, though that may or may not introduce some challenges. And short of collaboration, even, version control has the added benefit of allowing you to roll back changes if you completely rewrite something and then decide you don't like it, you can always revert back to a previous commit that has the older version of the part.

In order to use version control, I do the following:

1. Create a new folder where I will save my scores
2. In Windows Explorer, right click on the folder and click "Git create repository here..."
   This option is added by Tortoise
3. Open up MuseScore and start working on my score
4. Save my score in the git folder as an Uncompressed MuseScore score.
   This is the important bit. Your files should have the .mscx extension, not the .mscz extension. This is necessary so git can do a diff of your files. It can't diff the compressed scores.
5. Find the new file in Windows Explorer and Right-Click on it.
6. Hover over the "TortoiseGit >" option and click "Add"
7. Click OK
8. Click "Commit"
   * Note: Tortoise seems to skip the staging step and treat all previously versioned files as automatically staged. I usually use git from the command line, so I'm not sure how to use a staging environment with Tortoise. If you really want that, and can figure it out, it would be a nice addition to this documentation.
9. You'll see a message that says you need to set your name and email address.
   It'll open up the git config window for you to enter these. Just enter them at the top and then click the Global checkbox below so that it doesn't ask you every time you create a new repository.
10. Enter a commit message and click "OK." and then click "Close"
11. Your file should have a green check mark icon next to it.
12. Open your score, make changes and save it.
13. Your file should have a red Exclamation point next to it.
14. To see what changed, right click on it and hover over "Tortoise Git >" and click "Diff".
    This will open up a window that will show you what changed. Unfortunately, it's comparing the XML source code, so you won't actually see a WYSIWYG view of how the score was changed, so this is only marginally useful at the moment.
15. Periodically when you have a successful save, commit your changes.
    1. Right-Click on the file
       (or if you're working with multiple files, you can go up a level in Explorer and commit all changed files in the repository at once by right clicking on the folder),
    2. click "Git Commit... -> master..."
16. Enter your commit message.
    This is a good place to log what you changed so you have a record of it.
17. Click "OK" and "Close"

Now if you do have a corrupted score, do the following:

1. Find the file in Windows Explorer. It will have the Red Exclamation Point
2. Right click on it and hover over "Tortoise Git >"
3. Click "Revert." Your file will be restored to the previously committed state.
   You will lose all progress you made since the last time you committed, but if you think about it, you've already lost it. This is just limiting the damage. It's a lot better than losing everything, eh? Especially if you're working on Movement 5 of a symphony and your file gets corrupted! Yikes. So, you will have to determine how often you commit based on how much you're willing to risk losing. If you're super paranoid, you can commit after every save. A little less so and you can commit when you've reached "milestones" in your project. It's really up to you.

So the last thing that remains is to suggest native integration as a feature request. Just using Tortoise to interface with git solves the problem of not having a backup, makes it relatively easy to make and restore backups, and limits the amount of drive space your backups take up while still preserving a detailed change log, which provides additional features. But it's still a bit of manual work to do these backups. It smooths out when you get the hang of it, but it might cause headaches for some at first.

If versioning was integrated into MuseScore natively, however, it would/could provide the following benefits:

1. A menu/button to version your files without having to find them in Explorer.
2. Allow the user to configure their versioning experience
   (Use different scm systems like git, hg, svn; Use different hosts, github, bitbucket,etc).
3. Provide a WYSIWYG diff interface to show changes as musical scores rather than just xml code for easier diffing and merging.
4. Further, MuseScore.com could provide their own github/bitbucket clone that provides additional music related features for easier collaboration with remote teamates
   (like pull requests that show the diffs as scores rather than just code).

Thanks for the read and considering this. If nothing comes of this other than helping someone else get some security and peace of mind without having to worry about losing their work, then I'll be happy.

** Yes, I know that MuseScore does somewhat do its own backup with the ".[ScoreName].mscz," files, but as far as I can tell, it only backs up when you open the file, and not every time you save, so if you have a whole day's work, for example, you could still lose a ton of progress.