Feature suggestion: ability to set default export location to current or relative directory

For some large projects where I want to be able to review the development of a piece over time, I use folders as a kind of poor man’s version control system. Each day I am working, I duplicate the folder from the previous day, rename it to the new date

My Cool Thing
├─ 2024-10-22
│  ├─ 2024-10-22 My Cool Thing.dorico
│  └─ Flows from My Cool Thing
│     └─ 2024-10-22 My Cool Thing - Mvt. I.wav
├─ 2024-10-23
│  ├─ 2024-10-23 My Cool Thing.dorico
│  └─ Flows from My Cool Thing
│     ├─ 2024-10-23 My Cool Thing - Mvt. II.wav
│     └─ 2024-10-23 My Cool Thing - Mvt. IV.wav
└─ 2024-10-24
   ├─ 2024-10-24 My Cool Thing.dorico
   └─ Flows from My Cool Thing
      └─ 2024-10-24 My Cool Thing - Mvt. II.wav

There are lots of reasons not to do this, so I wouldn’t recommend it as a “default” workflow to anyone, but I have personal reasons for wanting to do this on this project, including both the ability to retrieve older versions on demand and the ability to share the development of the piece over time once it is done, if I so choose.

However, by default, the export location is always wherever that project was previously exported to. I can totally see why; it makes perfect sense for the normal workflow. However, because I am creating these copies of projects I would really love to not have to re-select the export location every time to have it export in the current day’s working directory! I would love to have a (maybe per-project?) setting that lets me always export in the same relative location, rather than the same absolute location.


It occurred to me while writing this that one obvious alternative here is to flip the way I work: just keep the current version of the project active at all times, and at the start of each day duplicate and “stash” it for the previous day’s work. I may use that approach going forward. It doesn’t quite solve all the same issues that my current approach does, though, in that one huge upside to my current workflow is that the project always has the date I was working on it attached, and so all the exports do so as well, so it’s less manual work on that end.

If folks have other workflow suggestions, I am all ears!

1 Like

You could use an actual version control system…?

There are pros and cons to this. Since Dorico files are binary, VCS can’t diff or merge them, so you’re pretty much limited to linear branches. But it is easy to add a new commit (version) whenever you want, and you don’t need to worry about naming the file or directory appropriately, since the VCS will timestamp it for you.

However, VCS would make it more difficult to open two or more versions of the file at the same time, in order to compare visually in Dorico or grab an older version of a section to paste into the newer document.

Yeah, this is exactly the issue. I am familiar with and have used the binary-friendlier approaches in the past, too, including Git LFS and Git Annex. They don’t really solve the issue in that they impose overhead without making it actually easy to do what I want with not only the Dorico files but also MP3s and PDFs. Alas!

I’m only glancingly familiar with Annex, but LFS was meant to improve on some of git’s limitations with large files (generally, > 50MB). These large files often tend to be binary, but LFS doesn’t really give git any magic powers in working with binary files.

(Which makes perfect sense. git can tell you that a certain range of bytes in a binary file has changed, but it has no idea what that change represents, or whether that change even corresponds to a semantic change in the file’s rendered contents.)

Yeah, and Annex is largely the same. Fundamentally, you need some way of providing semantic diff information, and the kind of blobs that binaries tend to be don’t generally do that. I have long had a will-never-get-to-it idea for a protocol (unless it happens to be something an employer actually decides to fund!) designed to enable that, but I think there’s a much better chance it would end up in a next-gen system like Jujutsu (jj) than in Git. (The jj devs have batted around some interesting ideas there, but there are higher priorities at present, and for good reason!) Net, real VCS doesn’t particularly address the needs I solve this clunky way.

1 Like