Mine is only one way. But it’s pretty easy. When you create duplicates they are assigned a number…if you click under that you can add a name. That is assigned to a variable that you can use in the export dialogue called $(version_name). So you can automatically have that added to your export file name and dice the JPG has the xmp data in its metadata then you can later use it as a sidecar…so this might work for you in most case
2 Likes
@priort
Great ! Very useful ! Your suggestion answers my question.
But that is not all ( 
): is there a way to set a duplicate in read-only ?
I mean disable any changes (of the history). I happened to have selected another duplicate by mistake and changed it.
I’m looking a way is to have an export that corresponds exactly to an history.
Since you have developer in your name, perhaps you know how to use git or another revision control system. XMP files are plain text. I check my XMPs into git so they’re versioned and my change history is there. I also check my raw files into git annex, but that is a story for another day.
2 Likes
Good suggestion. Another way would be to alter file permissions. But I prefer the git approach.
True !
Good suggestion.
Now I’ll investigating how keep linked xmp, exports and original raw files.
I don’t know git annex.
At work we are starting use ‘registry’ in GitLab, but It seems like annex in git. (I don’t know)…
If you are on WIndows you can use a little program called Autover to watch your folders for xmp and version them in a back up location of your choice…if not…recall what I said if you export an edit as a jpg the history is save with it…so you can simply apply that edit to a raw using that jpg and it will apply the edits you made to make that raw file…so really no need to mess around renaming them except in DT be sure to give your duplicates names to be able to use the version name variable as part of the exported JPG name…
The problem with making the xmp files read-only is that darktable will write the changes to the database anyways, so you end up with a conflict. If you catch the error fast you’ll know you need to overwrite the database with the xmp version, but after some time you’ll probably forget and start wondering which is the correct version.
Yes, true, unless you start darktable with --library :memory:
Are you looking for a possible feature in dt where a preference setting would turn on some extra processing, namely, when you output an image, dt would also output a copy of the XMP named the same as your image. You would then have a free-standing independent record of your edits.
@RawConvert
Yes, It is. I don’t have enough DT knowledge to say what’s best, with less impact.
Another option could be a simple (I believe) flag that put a duplicate in read-only.
It is like freezing a state of work.
In this way, after a duplicate export that satisfies you, manually set the read-only flag to true.
After that you have a history that matches the export.
It’s embedded in the JPG so it really overkill…
I don’t much like the history being in the jpeg. Seems odd someone has gone to all that trouble to design a compact file, then you go and stuff data in it which is irrelevant to most people who see the image! If I send someone a box of chocolates, I don’t enclose a map showing the route I took to the shop where I bought them! Some might even argue having the history in there is a privacy concern? And correct me if wrong, but the jpeg history is not 100% reliable because tags can be too big.
@Ric_Developer , I can see setting read-only is more secure, however dt does not access XMPs with a name other than “image file”.XMP (unless you explicitly tell it to, e.g. loading an existing xmp onto an image file) so perhaps you might be worrying too much about this?
Storing the history stack in the exported image file is optional, as is the use of sidecar files. So all that can be set according to your personal preferences.
As for the size, according to the manual:
“Entries in XMP tags can get rather large and may exceed the available space to store the history stack in some output files on export”. That’s probably which is why there is an option to store them in a compressed binary format.
Maybe yes. I’ll try to find the best suitable processing flow for me.
In general I like sidecar files, but not for all files even if not edited. So I disabled “write didecar for all images”.
I’m doing some tests.
In the next version of darktable you will be able to choose only to write sidecar files when you edit an image, rather than on import.
Great !!! 
Thanks, that’s good about “only write when edit”.
@rvietor , @priort , about tags in output, the manual (3.6) also says “Users are therefore advised to not rely on this feature for their backup strategy. To back up your data always make sure to save your input (raw) file as well as all of darktable’s XMP sidecar files.” (page 195)
Same question as the post, but with a different intent: how can I quickly save an .xmp file from lighttable to a specific location, eg in /tmp/, for subsequently posting in this forum?
Currently I look up the file in the relevant folder, but this is a bit tedious.
I don’t think you can just save the xmp in a “random” place. You can however export e.g. a medium-quality jpeg with the history stack in the metadata. That jpeg can then be used as if it were an xmp sidecar to load a history.
Added advantage: users get a quick preview of what your history stack does 
I was scolded for doing this and rightly so I guess as some people apparently just want to look at the txt file…if your version is not common from building or whatever it may not load as a sidecar but they could still read the text… at least that is what I recall I was told…