I’m working on an arrangement in Dorico and sharing with other collaborators, recording tracks against the arrangement tracks imported into Cubase, etc… I need some kind of version control. Something like GIT for computer code, but for all the files (not just text, which is a GIT limitation). If Dorico was more complete with regards to its MusicXML export feature, I could just export MusicXML into a GIT folder, but this will exclude things like chord symbols.
What do the pros use for version control on their Dorico (and Cubase) projects?
Some put a date-stamp in the title when they save the latest version: musicFile200321.dorico would be a files saved today. One could add a, b, and c after the yymmdd date-stamp to indicate multiple versions in a single day. It also lets similar files sort in date order.
This has the advantage of leaving the prior file as a backup (until one decided to delete it).
There is a Mac app called ForeverSave2, which automatically saves every X minutes and maintains each save as a separate file that can be browsed and restored. I dare say there’s a similar Windows app.
Manually doing anything for the benefit of the computer is the wrong way round, IMO!
In Cubase, when I’m working with a mastering engineer and files are going back and forth, I create new a new version of the Cubase Project using ‘save new version’ for each iteration. When I export an audio mixdown I put the version number as part of the file name. That way the project and mixdown files are linked.
Versioning is one of the very few features that I wish Dorico would incorporate from S**. My problem with all these methods is that there is no simple mechanism to associate a narrative/explanation with the previous versions. I.e. - why am I making a new version? Most typically it’s because I want to try something new in a piece but I do not want to lose the work I have done (in case I end up preferring the existing music). In S** you could create a version & give it some text - e.g. “Trying to do section X in 3/4 modulated down a third”. If I decide I prefer the previous version it is immediately available without having to open up new files.
My “solution” is to create a “leftovers” file for each project. If I need to preserve part of piece - for whatever reason - I copy that section into the leftovers file - and put in some text explaining why/what is going on. This invariably slows down my work flow.
Of course in Dorico, you can duplicate an existing flow within the same project, and mess about with it there, adding explanatory notes in the Project Info, or Comments. Or Export the Flow as a separate project.
Sibelius isn’t the Dark Lord. You can say its name.
These all work, but they’re all kludges - each with their own particular issues
Now you’re cluttering up your project. Even if I prefer the newer version I may want to keep the older version for reference - or “just in case”
Now you have multiple files - with no way of knowing why you created them (unless you keep a separate log file which means extra steps in your work flow.)
OK, here goes, I gonna try it. Sibelius. . . . OK, I haven’t been struck by lightning - yet . . . . .
This is brilliant! Thank you @A3eu for reactivating this thread and thank you @PaulWalmsley for mentioning it originally.
I just tested it with a project I’m working on. I added the dorico file to the repo. Then I changed the title and committed it to the new repo. Then I made another title change and committed that. I then rolled back to the original and it was unchanged liked I’d hoped.
I’ll add the VEPro Server file for this project to the repo, too, so I can manage changes I make there as well.
I can keep the project on GitHub and work either at home or at the studio and always have the latest version.
And I added a button for GitHub Desktop to my Notation Express profile!
You can’t merge Dorico files unfortunately because it’s a binary file format. Even if it used a text representation, you would most likely get lots of nasty conflicts due to reuse of internal IDs. So you can create git branches, but you won’t be able to merge them back.
I agree that this is something that would be so value in notation software. I am a veteran software developer and the thought of doing this type of work without the ability to look at version history makes me feel like I’m driving without a seat belt.
If suppose if you export to XML or some other text format, then you could see the changes you made in the version history. One of the digital design packages I use (Xilinx Vivado for you nerds) does something similar.
I know people think manual version control by saving with datestamps and other similar approaches is sufficient, but it’s just not the same. Things like branching (for different instrumentation for example) and merging in parts from multiple collaborators is done so much more easily and acccurately. Then, having a history of all that is so helpful and avoids a lot of the horror stories I always hear about where people lose or corrupt their work. It does seem like a music-based version control tool (or extension to git or similar) would be a game-changer.
It really ought to be in the File menu, regardless.
