I am trying to make a setup within the same Windows machine to continue running the stable darktable version and also have the test-development version installed.
This is what I did :
the stable version is by default installed in C:\Program Files\darktable
the test version is installed in C:\Program Files\darktableTWO
I start the stable version with the regular default shortcut.
I start the test version with a .bat file containing
@echo off
cd C:\Program Files\darktableTWO\bin
“C:\Program Files\darktableTWO\bin\darktable.exe” --library D:<user>\PICTURES\DarktableDbTWO\DTcatalogTWO.db --configdir D:<user>\PICTURES\DarktableDbTWO\DTsettingsTWO --tmpdir D:<user>\PICTURES\DarktableDbTWO\TempTWO --cachedir D:<user>\PICTURES\DarktableDbTWO\CacheTWO
So far this seems to work but It remains unclear whether I need the tmpdir argument as I see nothing appearing. Also my darktable-log.txt logfile is written in the same default folder of the main darktable instance.
Do you actually want two libraries… you can run DT with an option to use a temp database in memory for every session and then delete it… in this way you could use the test version as an editor… You should turn off writing xmp files for the test version unless you are keeping edits for the same images completely separate…you can use legacy edits in the new version but you can’t go back so be careful…
I do something similar but I just use a second shortcut… pointing to two folders…one for config files and one for the cache and temp…
You may also provide :memory: as the library file, in which case the database is kept in system memory – all changes are discarded when darktable terminates.
You can find this discussed many times on the forum.
There are two places to store the development stack:
XMP sidecar files
the library database.
If, using the development version, you open the library database created by the stable version, it will be upgraded.
For XMP sidecars, if you use new modules, or newer versions of existing modules, from the development version, the XMP will become incompatible with the stable one.
If you use the development version with an in-memory database, as Todd suggested, you will either have to write XMP sidecars (which can then become incompatible with the stable version), or lose all edits when you close darktable. If you maintain a separate directory where you only edit photos using the development version, this is a viable option, but using the in-memory database requires the same custom command to launch darktable as using a separate, permanent database.
I’d go with the separate databases, and set the development version not to write XMP sidecars. That way:
no separate ‘edit these using the development version’ directory is needed: the development version will read the existing XMPs on import, but not modify them;
the edits made using the development version are safely and separately stored in its own database.
Like many of us, I’ve been using the development version as my only installed instance for years, with hardly any problems (when they appear, I can report the issue, helping the developers, and maybe switch back to a slightly older one for a few days, then helptest the fix). I update it almost daily.
Thanks Kofa and Pehar for all this advice. I experienced that the dev’s react promptly on issues reported. I have been pretesting the development version the last 6 weeks prior to release date since version 4.3 as my single instance of dt. On 4.7 no issues so far during my regular workflow. But on 4.3 and 4.5 I had issues. With this separation of dt instances I may want to prudently start testing earlier on 4.9.
Thank you all: Todd, Kofa and Pehar.
Marc.