How to set up a darktable isolated sandbox

Software darktable
1

I want to experiment with a completely isolated parallel version of darktable, besides my regular install. I want to work on the same Linux box and filesystem.

I have compiled a new darktable binary and execute using:

./darktable --configdir <dir1> --cachedir <dir2>

Do I need to set more parameters? Like:

--datadir <data directory>
--moduledir <module directory>
--tmpdir <tmp directory>
...

I have checked the 4.2 manual for more parameters: darktable 4.2 user manual - darktable

I want to checkout old releases of darktable to do git bisect, but I do not want any interaction at all, with my regular installation of darktable.

What is the usual practice, in this case?

Edit: When I checkout:

git checkout release-4.0.1
git submodule update --recursive
./darktable --configdir $HOME/camera2/test2/darktable-bisect/.config --cachedir $HOME/camera2/test2/darktable-bisect/.cache

I get:

[dt_ioppr_check_so_iop_order] missing iop_order for module sigmoid
ERROR: iop order looks bad, aborting.
2

OK, I got it:

  • Delete old install directory.
  • Delete darktable build directory and reconfigure and rebuild
  • run: ./darktable --configdir dir1 --cachedir dir2
3

Turn off writing xmp for one version. THat might help avoid accidentally overwriting your xmp with something you didn’t want and making it so you can/t read it in the older version…so likely turn off for the test version…

2 Likes
4

@priort, do you mean: preferences > storage > write sidecar file for each image > never, for the test version?

Yes, that is a good idea. Thanks.

My default in git master 4.3.0 seem to be on import.

1 Like
5

I was suggesting that…then your test image edits will just rely on the database and you won’t have to worry about cross pollination …

6

So does it mean that the database contains what is there in the xmp file?
What happens when an update from the master branch corrupts the database file? (it has happened to me and I had restored from backup and now I have stopped upgrading from the master branch)
Is there a way to repair the database?
How to backup DT so by restoring it bring backs the previous version? Any script for this purpose?

7

Database is backup at the interval you specify in the preferences so you may have several copies… also i am only suggesting this for your test version…

For example I have lots of options for backup in addition to any I might set up another way…

image

I actually version my xmp so I can go back to any edited version that I might need to if anything ever gets messed up…

Little program called autover…

8

Still confused :confused: can you please elaborate.

9

You can simply copy any of the backup library files over library.db to restore that version.
If you are running 4.2, and want to try master, the first time you launch master will create library.db-pre-4.3.0. If you don’t like master, you can restore darktable 4.2, and copy library.db-pre-4.3.0 to library.db to restore the 4.2 version of the database.
There is no way to ‘repair’ the database: if, while on master, you try ‘super new module’ which is not present in 4.2, there is no way 4.2 would be able to process that module. If your database is corrupted some other way (say, data goes missing), then its integrity is compromised anyway.

The library.db-snp-yyyyMMddhhmmss files (like library-snp-20230123123456) are timestamped copies, you can always revert to those (the timestamp has the format yyyy (4-digit year) MM (2-digit month, like 01 for January) dd (2-digit day of month, e.g. 03 for 3rd) hhmmss (2-digit hours, like 00 for 12 AM, 03 for 3 AM, 12 for 12 PM, 15 for 3 PM; 2-digit minutes, 2-digit seconds).

1 Like