The difficulty managing files across multiple machines is not unique to Darktable. It's anywhere the CAP theorem is relevant. Even Adobe's Cloud.
Darktable's database is not the single source of truth. Functionally, it's an index over the XMP sidecar files. When it's deleted, rebuilding is 'simply' a matter of reimporting all the files. The XMP sidecar files are the actual data records...well ok, so are the images but they're immutable.
Local-sync's is inherently mutable state semantics. That's probably never what I want in my workflow. Disk space is cheap enough that I don't find an append only workflow cost prohibitive. Particularly since duplicating a Darktable image only consists of a new XMP file there's little point in overwriting an existing one to save a few bytes. [1]
Practically speaking, local-sync doesn't work for me because it munges filenames. This breaks my tiered backup logic...or rather complicates reasoning about it beyond the number of brain cells I can commit to it.
What I think I want is more tooling for operating outside of Darktable (I already ingest images from my camera with Rapid-Photo-Downloader). Two tools in particular. One which takes a list of XMP files and generates new XMP files based on Darktable's duplicate semantics. The other an inverted index of all the XMP documents. The goal is to move file operations outside of Darktable where they can be automated in the shell.
[1]; XMP files could be versioned with Git if duplicate files are a problem. They aren't for me.
Darktable's database is not the single source of truth. Functionally, it's an index over the XMP sidecar files. When it's deleted, rebuilding is 'simply' a matter of reimporting all the files. The XMP sidecar files are the actual data records...well ok, so are the images but they're immutable.
Local-sync's is inherently mutable state semantics. That's probably never what I want in my workflow. Disk space is cheap enough that I don't find an append only workflow cost prohibitive. Particularly since duplicating a Darktable image only consists of a new XMP file there's little point in overwriting an existing one to save a few bytes. [1]
Practically speaking, local-sync doesn't work for me because it munges filenames. This breaks my tiered backup logic...or rather complicates reasoning about it beyond the number of brain cells I can commit to it.
What I think I want is more tooling for operating outside of Darktable (I already ingest images from my camera with Rapid-Photo-Downloader). Two tools in particular. One which takes a list of XMP files and generates new XMP files based on Darktable's duplicate semantics. The other an inverted index of all the XMP documents. The goal is to move file operations outside of Darktable where they can be automated in the shell.
[1]; XMP files could be versioned with Git if duplicate files are a problem. They aren't for me.