Let me explain my question a bit more. I recently dabbled into AgX and used a couple of daily builds for that. That was a new experience for me. Realized I took some risk there. Also I like to Play Raw and sometimes unwantedly imported keywords into my keyword-hierarchy. And in the near future would not mind to participate in testing and/or documenting new features of darktable.
This lead me to the following: 1) I want a stable production install of an even numbered dt version, 2) the same but separate for playing raw, 3) a test install having whatever version of dt that is applicable.
Simple? Under the production installation I have styles, presets, keywords and all my actual settings. I want those - except maybe the keywords - available for play raw as well. I looked after the new āworkspaceā functionality but this shares the data.db and risks adding unwanted keywords in my hierarchy. So thatās a no go. And hopefully I can use the same data in the test-installation too.
I want to set configdir values differently for all three installs. So on my disk I may recognize the subsequent folders. For the test install I want to use a separate copy of a year worth of pictures and their .xmp files. So no fear at all of corrupting anything.
So my question is: do I run into problems copying the data.db, all rc files, user.css and the lua folder over to the play raw and test folders? Iām afraid I will as I understood there are references between the library.db and data.db.
And when this is not possible how then to achieve my goal? For instance exporting/importing styles and presets and copying the other none .db files would that work? Or will I copy both library.db and data.db and then remove unwanted pictures and keywords? What are your experiences maintaining this slightly more complicated setup?
Quite possibly I miss obvious chances because of lack of knowledge here. Please be a bit kindā¦
It sounds like one way you can go is to use the new feature to have 1 and 2 set upā¦second database for playraw stuff if you even need that but maybe you would like it and for 3 you can install the test version separately and use the :memory: option of the --library option for a virutal library thus using this version like a program with no dam just as an editor and then you can open up your test files as you are keeping them separate
This is exactly what was my goal too.
In mac osx
I created a different folders for each instance of dt in my .config folder. Each instance of dt will start from command line of
choose a different name for each instances of āeach-instance-nameā folder.
initially copied all the files and folders from my only instance to other instances. Subsequently, each may change as they are isolated from each other.
This step is optional:
Created a script wrapper for the command-line.
Finally, as precaution and to completely isolate each instances I turned off the creation of xmp files and will turn it on as needed for export only. Otherwise you may need to keep track of the xmp files as not to create issues of inconsistency and out of sync of the images developed by each instances of the dt
BTW,
I did the same thing for my linux virtualbox.
Yeah thatā nearly exactly what I intend! Nice. Iām on Ubuntu 24.04.3.
Just curious what this does?
This I want to avoid, being afraid forgetting to turn it of. That is why I created a separate picture folder both for the Play-Raw install and for the Test install. The Test install uses a copy of my 2025 folder.
As far as I found on basis of a daily build (+733) the āmultiple workspacesā option shares the data.db with the original install. Meaning - I think - that when I import playraw pictures with keywords in them my keyword list will be filled with tags I do not want.
So far Iāve choosen the route to copy over all relevant files from my āproductionā to the test install. Delete all pictures. And import a copy of my 2025 folder, including .xmp files. Will test and report back - issues or not.
To avoid typing each time the full command, just run the shell file.
I have this old free app that was developed by Carsten Blum called Pashua. I can create a gui app that I can choose different instances.
I have extensively wrote many app and wrappers using it.
Unfortunately , works in osx. I believe there are similar utility apps in linux.
below is a example of one of the variations:
I donāt use key words much but I thought you could import without metadata maybe I am wrongā¦ but if you forgot I guess then your list would be corruptedā¦
