Working on an image in dt 3.4.1 under Win 10. I have made a duplicate of it and applied some edits to the ‘version 1’. I then transferred the raw file and xmp outside of dt to my linux machine , where I imported the image into dt 3.4.1 under Linux Mint 20.1.
I don’t see versions 0 and 1 while the image I do see is certainly neither version 0 nor version 1, with totally unexpected colour changes. Are my expectations inappropriate?
I think versions are tracked in the database…someone can correct me…so likely when you transfer you lose that connection
When creating a duplicate there’s also a new corresponding xmp file created. Original xmp will be named: image.raw.xmp and first duplicate will be: image_01.raw.xmp
You mention that you copied the RAW and xmp file (singular) from Windows and that you do not see the duplicate on the Linux box after transfer. This is correct, you need to copy both (or all if more duplicates exist) xmp files (and do a new folder import).
All this is also in the database (library.db), but that is just for internal convenience/speed. darktable is set up in a way that it will not loose edits when something happens to the software itself. This includes all the duplicates. At any time you can delete the software, reinstall and then reimport and all will be there again.
However…
You cannot go from a higher to a lower darktable version and I do believe that is/might (also?) be the problem in your example.
Version 3.4.1 for Windows was critically flawed and I’m assuming that you installed the fixed Windows version, which would be 3.4.1.1. The current Linux/MacOS version is 3.4.1. I can’t find it any more but I do recall reading somewhere that this is indeed a problem when you try to share xmps between the 2 (3.4.1.1->3.4.1 to be exact) (@elstoc: any developers here that can acknowledge/deny this?)
Fixed a word.
I doubt the differences between 3.4.1.1 and 3.4.1 would break compatibility of edits / XMP files. Backward compatibility is not explicitly linked to darktable versions but specific types of change within darktable.
I can’t recall the sequence exactly but I have had instances where I have updated to a new build or cleaned things up and upon importing the file the duplicate xmp files were not recognized. I can’t recall the exact sequence of events sadly but I know it has happened on more than one occasion…I do edit the same files from different PC’s and I may have had a version mismatch , ie trying to load newer ones in to an older version but I can’t really say only that I know it can happen that you have the xmp files in place but they don’t import as duplicates…if I notice it again I will document it…I have not noticed this recently I might add
A most helpful explanation - thank you.
I had persuaded myself that the edits for additional versions would all be contained within the one .xmp - I could see no reason why there couldn’t be tags within the xml to allow the definition of different ‘sections’ for each different image version within the xmp. I even persuaded my self that this was good architectural design, maintaining a consistent approach. I went as far as browsing the xmp to prove that both versions’ edits were contained there-in and explained away my failure to find them as being caused by my inability to read/parse the xml. Furthermore, I ignored the additional ‘.01’ xmp altogether as being a legacy of having used that particular image repeatedly for testing my understanding of darktable, LightRoom, photoshop, Capture One and so on. So, I did indeed transfer just the one xmp file. Now I know better.
Yes, I am using 3.4.1.1 in Windows and the original 3.4.1 in Linux as I am aware that the defect that was corrected in 3.4.1.1 was not presented in the Linux version of 3.4.1. But what I did not appreciate is the possibility of not being able to ‘round trip’ between op. sys versions which are only a .x.x.x.1 level apart.
I think I’m going to see if this is possible (edit under Win 10, xfer to Linux, make additional edits, xfer back to Win 10) on another image without versions. I want to try this because I much prefer to use dt under Linux but the (significantly) more powerful computer running my LightRoom/Photoshop set-up - which I still need from time to time, until such time as I have adequate skills in dt - is Windows only (obviously).
I have a, somewhat too strict a rule of thumb that a lower version cannot use xmps from a higher version, which isn’t always the case. But that is not based on versions being x.x.x.1 apart, as is the case here. As mentioned by elstoc compatibility is probably not influenced in this case, but the only way to make sure is testing it with some dummy edits and copying them. I do not run Windows so I cannot confirm/deny if this works.
If you run into that and it is reproducible you should definitely file a bug report 'cause that shouldn’t happen. I don’t think you actually lose any edits though; You can always use ctrl-d to create a duplicate and load the xmp file manually with the load sidecar file option, which might be a bit annoying but at least you do not have to redo any edits 
Correct you just need to reload them on a new duplicate……
I’ve just completed a test, taking an image, under Win 10/3.4.1.1, with a history stack about 20 steps deep (after compression), transferring it plus its xmp, while dt is closed, to Linux, importing it (as a ‘never seen before’ item); opening in darkroom, getting the results I expected, editing it further to a history stack of 35 steps (without compression), transferring it plus xmp back to Win10 (again, with dt closed), renaming the existing Win 10 xmp, importing the image back into dt under Win 10.
Dt warned me about an updated version of the sidecar file, which I elected to load, but the history stack was not updated to the Linux state until I removed that image and re-imported it. Not what I expected, but not a show-stopper by any means. There is just no notification that the history stack has not been updated, so it would be easy to be mislead into thinking you are working on the image in the state that it was in the ‘other’ computer/op. sys, so, as a result, possibly lose the edits from the ‘other’ computer.
Next test, I will try to round trip an image with a duplicate - later.
Later
Yep, round-trip between OSs and between minimal code version differences, with duplicates, works; no immediate or obvious issues detected. Need to be careful to back up then remove images from originating installation of dt.
I would actually call this a bug.
A while back I would edit photos on both my Linux desktop and Windows laptop (having the images and XMPs located on a NAS) and I’m pretty sure my edits propagated from one dt installation to the other this way (let dt reload the XMP on startup).
I currently don’t have access to my Windows machine and haven’t tried it with dt 3.4.x nor 3.2.1 but I’m rather sure it used to work with dt 2.4, 2.6 and probably even 3.0.
I have done the same. Set DT in preference to look for updated xmp. I did this for multiple PC
s as well and it usually worked but I got bitten a few times when my local folder had not yet been fully sync’d before I loaded DT so it used the database as that seemed like the newest version as far as DT was concerned. SInce I don’t really use any of the DAM features in DT I switched to using memory as my library option so basically DT uses only the xmp and reads it fresh each time. I have had little to no problem moving between systems since I started using DT this way and skipping the database.